Files
msolarczekandClaude Opus 5 c8e6f30a27
CI / build-and-check (push) Canceled after 0s
CI / audit (push) Canceled after 0s
CI / sbom (push) Canceled after 0s
Basis: Certvia dev@a48c5fb als Fundament für Craftvia
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation
und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 11:05:39 +02:00

3779 lines
224 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# C6 — Umsetzungshinweise je Teilanforderung
> **Schaltet frei:** B5 (Umsetzungshinweise-Panel) + A7 (Control-Assessment). **Grundlage:** `mapping.json` (Anforderungs-IDs) + Proto/DS-Dekomposition.
> Je Anforderung: organisatorische & technische Umsetzungsoption, typische Nachweise, Vorlagen-Verweis, Ressourcenindikation, AL-Filter. Ressourcen-Hinweise mit Beschaffungs-/Umsetzungsbedarf führen im Wizard zu einer Aufgabe.
---
# Kapitel 1 — Governance & Organisation
# C6 — Umsetzungshinweise Kapitel 1 (Informationssicherheitspolitik & Organisation)
## Control 1.1.1 — Inwieweit werden Informationssicherheitsrichtlinien erstellt und kommuniziert?
### 1.1.1-M1 — [MUSS]
**Anforderung:** Anforderungen der Informationssicherheit sind bestimmt, dokumentiert und an den Organisationszielen ausgerichtet.
- **Organisatorisch:** Sicherheitsanforderungen aus Geschäftszielen, Kunden-/Vertrags- und Gesetzeslage ableiten und in der Leitlinie verankern; Ableitung dokumentieren und von der Leitung bestätigen lassen.
- **Technisch:** Leitliniendokument versioniert im Dokumentenmanagement/DMS ablegen; Freigabe- und Änderungshistorie technisch nachvollziehbar führen.
- **Typische Nachweise:** genehmigte Leitlinie mit Zielbezug; Übersicht abgeleiteter Anforderungen; Freigabevermerk der Leitung.
- **Vorlage:** L00
- **Ressourcen:** ISB/CISO; ca. 1–2 PT für Erstellung/Abstimmung; kein Toolbudget (vorhandenes DMS).
- **AL-Filter:** AL2 + AL3
### 1.1.1-M2 — [MUSS]
**Anforderung:** Eine durch die Leitung genehmigte Leitlinie existiert.
- **Organisatorisch:** Formalen Genehmigungsakt durch die oberste Leitung durchführen (Managementbeschluss, Unterschrift); Genehmigung datieren.
- **Technisch:** Signierte/freigegebene Version zentral und unveränderbar (read-only) bereitstellen.
- **Typische Nachweise:** unterschriebene/freigegebene Leitlinie; Protokoll- oder Beschlussvermerk der Leitung.
- **Vorlage:** L00
- **Ressourcen:** Leitung + ISB; gering (Termin/Freigabe).
- **AL-Filter:** AL2 + AL3
### 1.1.1-M3 — [MUSS]
**Anforderung:** Die Leitlinie benennt Ziele und Bedeutung der Informationssicherheit.
- **Organisatorisch:** Abschnitt „Ziele und Stellenwert der Informationssicherheit" in die Leitlinie aufnehmen; Bezug zu Schutzzielen (C/I/A) herstellen.
- **Technisch:** Keine spezifische technische Maßnahme; Inhalt im Leitliniendokument.
- **Typische Nachweise:** Leitlinie mit Ziel- und Bedeutungskapitel.
- **Vorlage:** L00
- **Ressourcen:** ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.1.1-M4 — [MUSS]
**Anforderung:** Leitlinien werden den Beschäftigten in geeigneter Form bereitgestellt (z. B. Intranet).
- **Organisatorisch:** Verbindlichen Veröffentlichungsweg festlegen; Bereitstellung in Onboarding-Prozess aufnehmen.
- **Technisch:** Veröffentlichung im Intranet/Mitarbeiterportal mit Lesebestätigung; Zugriff für alle Beschäftigten sicherstellen.
- **Typische Nachweise:** Intranet-Link/Screenshot; Verteil- oder Lesebestätigungen.
- **Vorlage:** L00
- **Ressourcen:** IT/Kommunikation; gering.
- **AL-Filter:** AL2 + AL3
### 1.1.1-M5 — [MUSS]
**Anforderung:** Beschäftigte und externe Geschäftspartner werden über relevante Änderungen informiert.
- **Organisatorisch:** Kommunikationsprozess für Richtlinienänderungen definieren (Zielgruppen, Kanäle, Auslöser); externe Partner über definierte Ansprechstellen einbinden.
- **Technisch:** Automatisierte Change-Benachrichtigung (Intranet-News, Verteiler) beim Publizieren neuer Versionen.
- **Typische Nachweise:** Änderungsmitteilungen; Verteilernachweise; Kommunikationsprotokoll.
- **Vorlage:** L00
- **Ressourcen:** ISB/Kommunikation; gering, laufend.
- **AL-Filter:** AL2 + AL3
### 1.1.1-S1 — [SOLL]
**Anforderung:** Anforderungen basieren auf der Organisationsstrategie; Gesetze und Verträge werden berücksichtigt.
- **Organisatorisch:** Strategie-, Rechts- und Vertragsanforderungen systematisch erheben (Legal/Compliance einbeziehen) und Bezug in der Leitlinie herstellen.
- **Technisch:** Verweis-/Anforderungsregister (Legal-Register) pflegen und mit der Leitlinie verknüpfen.
- **Typische Nachweise:** Anforderungs-/Rechtsregister; Leitlinie mit Strategie- und Rechtsbezug.
- **Vorlage:** L00
- **Ressourcen:** ISB + Legal; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.1.1-S2 — [SOLL]
**Anforderung:** Die Leitlinie benennt Konsequenzen bei Nichteinhaltung.
- **Organisatorisch:** Sanktions-/Konsequenzenklausel abstimmen (HR, Betriebsrat) und in die Leitlinie aufnehmen.
- **Technisch:** Keine; Inhalt im Dokument.
- **Typische Nachweise:** Leitlinienabschnitt zu Konsequenzen; Betriebsrats-/HR-Abstimmung.
- **Vorlage:** L00
- **Ressourcen:** ISB + HR; gering.
- **AL-Filter:** AL2 + AL3
### 1.1.1-S3 — [SOLL]
**Anforderung:** Weitere relevante Sicherheitsrichtlinien sind etabliert.
- **Organisatorisch:** Richtlinienlandkarte aufbauen; themenspezifische Richtlinien (Zugriff, Kryptografie, mobiles Arbeiten etc.) aus dem Vorlagensatz ableiten und freigeben.
- **Technisch:** Richtliniensammlung strukturiert im DMS mit Gültigkeits-/Reviewständen.
- **Typische Nachweise:** Richtlinienübersicht; freigegebene Einzelrichtlinien.
- **Vorlage:** L00; R01–R14
- **Ressourcen:** ISB; mehrere PT je nach Umfang.
- **AL-Filter:** AL2 + AL3
### 1.1.1-S4 — [SOLL]
**Anforderung:** Regelmäßige Überprüfung und ggf. Überarbeitung der Richtlinien ist etabliert.
- **Organisatorisch:** Review-Zyklus (z. B. jährlich) und anlassbezogene Prüfung festlegen; Verantwortliche und Termine definieren.
- **Technisch:** Wiedervorlage-/Review-Erinnerungen im DMS oder GRC-Tool setzen.
- **Typische Nachweise:** Review-Plan; Änderungshistorie mit Prüfdatum.
- **Vorlage:** L00; VA-15
- **Ressourcen:** ISB; gering, laufend.
- **AL-Filter:** AL2 + AL3
## Control 1.2.1 — Inwieweit wird Informationssicherheit in der Organisation gemanagt (ISMS)?
### 1.2.1-M1 — [MUSS]
**Anforderung:** Der Geltungsbereich des ISMS ist definiert.
- **Organisatorisch:** Scope nach Standorten, Organisationseinheiten, Prozessen und Dienstleistungen abgrenzen und begründen; Schnittstellen/Ausschlüsse dokumentieren.
- **Technisch:** Scope-Dokument im ISMS/GRC-Tool hinterlegen und mit Asset-/Standortlisten verknüpfen.
- **Typische Nachweise:** Scope-Dokument; Standort-/Bereichsübersicht.
- **Vorlage:** R01
- **Ressourcen:** ISB; ca. 1–2 PT.
- **AL-Filter:** AL2 + AL3
### 1.2.1-M2 — [MUSS]
**Anforderung:** Die Anforderungen der Organisation an das ISMS sind bestimmt.
- **Organisatorisch:** Interessierte Parteien und deren Anforderungen (Kunden, Regulatorik, intern) erheben und dokumentieren.
- **Technisch:** Anforderungsregister im GRC-Tool führen.
- **Typische Nachweise:** Kontext-/Stakeholder-Analyse; Anforderungsliste.
- **Vorlage:** R01
- **Ressourcen:** ISB; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.2.1-M3 — [MUSS]
**Anforderung:** Die Organisationsleitung hat das ISMS beauftragt und genehmigt.
- **Organisatorisch:** Formalen Auftrag/Mandat der Leitung für das ISMS und den ISB erteilen und dokumentieren.
- **Technisch:** Keine; Beschlussdokument.
- **Typische Nachweise:** ISMS-Auftrag/Mandat; Leitungsbeschluss.
- **Vorlage:** R01
- **Ressourcen:** Leitung + ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.2.1-M4 — [MUSS]
**Anforderung:** Das ISMS stellt der Leitung Mittel zur Überwachung und Steuerung bereit (z. B. Managementbewertung).
- **Organisatorisch:** Managementbewertung (Management-Review) mit Turnus, Input (Kennzahlen, Audits, Vorfälle, Risiken) und Output (Maßnahmen) etablieren.
- **Technisch:** ISMS-Kennzahlen/Dashboard im GRC-Tool bereitstellen.
- **Typische Nachweise:** Management-Review-Protokoll; ISMS-Kennzahlenbericht.
- **Vorlage:** R01; VA-15
- **Ressourcen:** ISB + Leitung; gering, periodisch.
- **AL-Filter:** AL2 + AL3
### 1.2.1-M5 — [MUSS]
**Anforderung:** Die anwendbaren Controls sind bestimmt (z. B. Anwendbarkeitserklärung/ausgefüllter ISA-Katalog).
- **Organisatorisch:** Anwendbarkeit je Control festlegen und begründen (SoA/ISA); Verantwortliche zuordnen.
- **Technisch:** SoA/ISA-Katalog im GRC-Tool pflegen und mit Maßnahmen verknüpfen.
- **Typische Nachweise:** Statement of Applicability / ausgefüllter ISA-Katalog.
- **Vorlage:** R01
- **Ressourcen:** ISB; ca. 2–3 PT.
- **AL-Filter:** AL2 + AL3
### 1.2.1-M6 — [MUSS]
**Anforderung:** Die Wirksamkeit des ISMS wird regelmäßig durch die Leitung überprüft.
- **Organisatorisch:** Wirksamkeitsprüfung als festen Bestandteil des Management-Reviews mit Bewertungskriterien verankern.
- **Technisch:** Trend-/Kennzahlenauswertung (Vorfälle, Audits, Maßnahmenumsetzung) automatisiert bereitstellen.
- **Typische Nachweise:** Management-Review mit Wirksamkeitsbewertung; abgeleitete Verbesserungsmaßnahmen.
- **Vorlage:** R01; VA-15
- **Ressourcen:** ISB + Leitung; gering, periodisch.
- **AL-Filter:** AL2 + AL3
## Control 1.2.2 — Inwieweit werden Verantwortlichkeiten für Informationssicherheit organisiert?
### 1.2.2-M1 — [MUSS]
**Anforderung:** Verantwortlichkeiten für Informationssicherheit sind definiert, dokumentiert und zugewiesen.
- **Organisatorisch:** Rollen (ISB, Risk Owner, Asset Owner) und Verantwortlichkeiten festlegen und namentlich zuweisen; RACI erstellen.
- **Technisch:** Rollen-/Verantwortlichkeitsmatrix im DMS/GRC-Tool pflegen.
- **Typische Nachweise:** Rollenbeschreibungen; RACI-Matrix; Bestellungsschreiben ISB.
- **Vorlage:** R01
- **Ressourcen:** ISB + HR; ca. 1–2 PT.
- **AL-Filter:** AL2 + AL3
### 1.2.2-M2 — [MUSS]
**Anforderung:** Die verantwortlichen Beschäftigten sind definiert, qualifiziert und befähigt.
- **Organisatorisch:** Qualifikationsanforderungen je Rolle definieren; Schulungen/Zertifizierungen sicherstellen.
- **Technisch:** Qualifikations-/Schulungsnachweise im Schulungssystem dokumentieren.
- **Typische Nachweise:** Qualifikations-/Zertifikatsnachweise; Schulungsdokumentation.
- **Vorlage:** R01; VA-12
- **Ressourcen:** HR + ISB; Schulungsbudget je Rolle.
- **AL-Filter:** AL2 + AL3
### 1.2.2-M3 — [MUSS]
**Anforderung:** Die erforderlichen Ressourcen stehen zur Verfügung.
- **Organisatorisch:** Personal- und Budgetbedarf des ISMS ermitteln und durch die Leitung bereitstellen lassen; im Management-Review nachhalten.
- **Technisch:** Keine; Ressourcenplanung.
- **Typische Nachweise:** Budget-/Ressourcenfreigabe; Stellen-/Kapazitätsplan.
- **Vorlage:** R01
- **Ressourcen:** Leitung; Budget-/Personalzuweisung erforderlich.
- **AL-Filter:** AL2 + AL3
### 1.2.2-M4 — [MUSS]
**Anforderung:** Ansprechpartner sind innerhalb der Organisation und bei relevanten Geschäftspartnern bekannt.
- **Organisatorisch:** Ansprechpartner der Informationssicherheit intern und gegenüber Partnern kommunizieren; Aktualisierung sicherstellen.
- **Technisch:** Kontaktverzeichnis im Intranet/Portal bereitstellen.
- **Typische Nachweise:** Intranet-Kontaktseite; Kommunikation an Partner.
- **Vorlage:** R01
- **Ressourcen:** ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.2.2-S1 — [SOLL]
**Anforderung:** Eine angemessene Informationssicherheitsstruktur ist definiert und dokumentiert.
- **Organisatorisch:** Aufbau-/Ablauforganisation der Informationssicherheit (Gremien, Berichtswege, Eskalation) beschreiben.
- **Technisch:** Organigramm/Strukturdokument im DMS.
- **Typische Nachweise:** IS-Organigramm; Gremien-/Berichtsstruktur.
- **Vorlage:** R01
- **Ressourcen:** ISB; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.2.2-S2 — [SOLL]
**Anforderung:** Sicherheitsrelevante Rollen außerhalb des ISMS werden berücksichtigt.
- **Organisatorisch:** Schnittstellenrollen (Datenschutz, Werkschutz, IT-Betrieb, Notfallmanagement) identifizieren und in die IS-Struktur einbinden.
- **Technisch:** Erweiterte Rollenmatrix mit Schnittstellen dokumentieren.
- **Typische Nachweise:** Rollenübersicht inkl. Schnittstellenrollen.
- **Vorlage:** R01
- **Ressourcen:** ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.2.2-H1 — [HOCH]
**Anforderung:** Angemessene organisatorische Trennung von Verantwortlichkeiten (Funktionstrennung) zur Vermeidung von Interessenkonflikten. (C, I, A)
- **Organisatorisch:** Funktionstrennung (SoD) definieren; kritische Kombinationen identifizieren und trennen; kompensierende Kontrollen bei Kleinstteams festlegen.
- **Technisch:** SoD-Regeln in Berechtigungskonzepten und IAM-Rollen abbilden und prüfen.
- **Typische Nachweise:** SoD-Matrix; Berechtigungskonzept mit Trennungsregeln; Ausnahmedoku.
- **Vorlage:** R01; VA-03
- **Ressourcen:** ISB + IT; ca. 1–2 PT; ggf. IAM-Konfiguration.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 1.2.3 — Inwieweit werden Informationssicherheitsanforderungen in Projekten berücksichtigt?
### 1.2.3-M1 — [MUSS]
**Anforderung:** Projekte werden unter Berücksichtigung der Informationssicherheitsanforderungen klassifiziert.
- **Organisatorisch:** IS-Klassifizierung als verpflichtenden Schritt im Projekt-Gate/-Freigabeprozess verankern.
- **Technisch:** Klassifizierungsfeld/Checkliste im Projekt-/PM-Tool hinterlegen.
- **Typische Nachweise:** klassifizierte Projektliste; Projektfreigaben mit IS-Einstufung.
- **Vorlage:** R01; VA-19
- **Ressourcen:** PMO + ISB; gering, laufend.
- **AL-Filter:** AL2 + AL3
### 1.2.3-S1 — [SOLL]
**Anforderung:** Verfahren und Kriterien für die Projektklassifizierung sind dokumentiert.
- **Organisatorisch:** Klassifizierungskriterien (Datenschutzbedarf, Kundenbezug, Kritikalität) und Verfahren beschreiben und freigeben.
- **Technisch:** Kriterienkatalog im PM-Tool/DMS verfügbar machen.
- **Typische Nachweise:** dokumentiertes Klassifizierungsverfahren; Kriterienkatalog.
- **Vorlage:** R01; VA-19
- **Ressourcen:** ISB + PMO; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.2.3-S2 — [SOLL]
**Anforderung:** In früher Projektphase erfolgt eine Risikobewertung nach definiertem Verfahren; Wiederholung bei Änderungen.
- **Organisatorisch:** Risikobewertung als Pflicht-Deliverable früher Projektphasen und bei wesentlichen Änderungen festlegen.
- **Technisch:** Risikobewertungsvorlage mit Projekt-Workflow verknüpfen.
- **Typische Nachweise:** Projekt-Risikobewertungen; Änderungs-Trigger-Doku.
- **Vorlage:** R01; VA-19; VA-09
- **Ressourcen:** Projektleitung + ISB; je Projekt.
- **AL-Filter:** AL2 + AL3
### 1.2.3-S3 — [SOLL]
**Anforderung:** Für identifizierte Risiken werden Maßnahmen abgeleitet und im Projekt berücksichtigt.
- **Organisatorisch:** Maßnahmen aus der Risikobewertung in Projektplan/-backlog überführen und nachverfolgen.
- **Technisch:** Maßnahmen als Tasks im PM-Tool mit Verantwortlichen/Terminen führen.
- **Typische Nachweise:** Maßnahmenliste je Projekt; Statusnachverfolgung.
- **Vorlage:** R01; VA-19
- **Ressourcen:** Projektteam; je Projekt.
- **AL-Filter:** AL2 + AL3
### 1.2.3-H1 — [HOCH]
**Anforderung:** Abgeleitete Maßnahmen werden im Projektverlauf regelmäßig überprüft und bei geänderten Bewertungskriterien neu bewertet. (C, I, A)
- **Organisatorisch:** Periodische Reviews der Projektmaßnahmen in Projektsteuerung/Gates verankern; Trigger für Neubewertung definieren.
- **Technisch:** Review-Termine/Reminder und Statusfelder im PM-Tool automatisieren.
- **Typische Nachweise:** Review-Protokolle; aktualisierte Risiko-/Maßnahmenstände.
- **Vorlage:** R01; VA-19; VA-09
- **Ressourcen:** Projektleitung + ISB; laufend.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 1.3.1 — Inwieweit sind Informationswerte identifiziert und erfasst?
### 1.3.1-M1 — [MUSS]
**Anforderung:** Informationswerte und weitere sicherheitsrelevante Assets sind identifiziert und erfasst.
- **Organisatorisch:** Erhebungsverfahren und Verantwortliche (Asset Owner) festlegen; Informationswerte je Bereich erheben.
- **Technisch:** Asset-Inventar/CMDB aufbauen und pflegen; Eindeutige IDs vergeben.
- **Typische Nachweise:** Asset-/Informationswert-Inventar; Owner-Zuordnung.
- **Vorlage:** R02; VA-08
- **Ressourcen:** ISB + Fachbereiche; ggf. Inventar-/CMDB-Tool (Beschaffung möglich).
- **AL-Filter:** AL2 + AL3
### 1.3.1-M2 — [MUSS]
**Anforderung:** Die unterstützenden Assets, die Informationswerte verarbeiten, sind identifiziert und erfasst.
- **Organisatorisch:** Abhängigkeiten zwischen Informationswerten und unterstützenden Assets (Systeme, Anwendungen, Standorte, Dienstleister) erheben.
- **Technisch:** Verknüpfung Informationswert ↔ unterstützendes Asset in der CMDB abbilden.
- **Typische Nachweise:** Inventar unterstützender Assets; Abhängigkeits-/Mapping-Übersicht.
- **Vorlage:** R02; VA-08
- **Ressourcen:** IT + Fachbereiche; laufend.
- **AL-Filter:** AL2 + AL3
### 1.3.1-S1 — [SOLL]
**Anforderung:** Ein Katalog relevanter Informationswerte existiert; einschlägige Aspekte werden berücksichtigt.
- **Organisatorisch:** Strukturierten Katalog mit Attributen (Owner, Klassifizierung, Speicherort, Aufbewahrung) etablieren und pflegen.
- **Technisch:** Katalog in Inventar-Tool mit Pflichtfeldern und Aktualisierungsroutine.
- **Typische Nachweise:** Informationswert-Katalog mit Attributen.
- **Vorlage:** R02; VA-08
- **Ressourcen:** ISB; laufend.
- **AL-Filter:** AL2 + AL3
## Control 1.3.2 — Inwieweit werden Informationswerte klassifiziert und geschützt?
### 1.3.2-M1 — [MUSS]
**Anforderung:** Ein konsistentes Schema zur Klassifizierung hinsichtlich Vertraulichkeit ist vorhanden.
- **Organisatorisch:** Vertraulichkeitsstufen (z. B. öffentlich/intern/vertraulich/streng vertraulich) mit Kriterien definieren und freigeben.
- **Technisch:** Klassifizierungsschema in Vorlagen/Labels (z. B. Klassifizierungstool) verankern.
- **Typische Nachweise:** freigegebenes Klassifizierungsschema mit Stufen/Kriterien.
- **Vorlage:** R02; VA-08
- **Ressourcen:** ISB; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.3.2-M2 — [MUSS]
**Anforderung:** Informationswerte werden nach definierten Kriterien bewertet und dem Schema zugeordnet.
- **Organisatorisch:** Asset Owner klassifizieren ihre Informationswerte; Vollständigkeit prüfen.
- **Technisch:** Klassifizierungsattribut im Inventar/CMDB pflegen; ggf. Labeling in Dokumenten.
- **Typische Nachweise:** klassifiziertes Inventar; Stichprobe klassifizierter Werte.
- **Vorlage:** R02; VA-08
- **Ressourcen:** Fachbereiche + ISB; laufend.
- **AL-Filter:** AL2 + AL3
### 1.3.2-M3 — [MUSS]
**Anforderung:** Vorgaben zur Handhabung unterstützender Assets abhängig von der Klassifizierung sind vorhanden und umgesetzt (Kennzeichnung, Nutzung, Transport, Speicherung, Rückgabe, Löschung/Vernichtung).
- **Organisatorisch:** Handhabungsmatrix je Klassifizierungsstufe (inkl. Löschung/Vernichtung) definieren und schulen.
- **Technisch:** Technische Kontrollen umsetzen (Verschlüsselung, Zugriffsrechte, sichere Löschung/Datenträgervernichtung) passend zur Stufe.
- **Typische Nachweise:** Handhabungsrichtlinie/-matrix; Lösch-/Vernichtungsnachweise.
- **Vorlage:** R02
- **Ressourcen:** ISB + IT; ggf. Beschaffung Vernichtungs-/Verschlüsselungslösung.
- **AL-Filter:** AL2 + AL3
### 1.3.2-S1 — [SOLL]
**Anforderung:** Die Schutzziele Integrität und Verfügbarkeit werden berücksichtigt.
- **Organisatorisch:** Klassifizierung um Integritäts- und Verfügbarkeitsstufen erweitern; Kriterien definieren.
- **Technisch:** I-/A-Attribute im Inventar; abgeleitete Schutzmaßnahmen (z. B. Backup nach BL-OPS-05) zuordnen.
- **Typische Nachweise:** erweitertes Schema C/I/A; klassifizierte Werte inkl. I/A.
- **Vorlage:** R02; VA-08; BL-OPS-05
- **Ressourcen:** ISB; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
## Control 1.3.3 — Inwieweit ist sichergestellt, dass nur bewertete und freigegebene externe IT-Dienste genutzt werden?
### 1.3.3-M1 — [MUSS]
**Anforderung:** Externe IT-Dienste werden nicht ohne ausdrückliche Bewertung und Umsetzung der IS-Anforderungen genutzt; einschlägige Aspekte werden berücksichtigt.
- **Organisatorisch:** Verpflichtende IS-Bewertung vor Nutzung externer IT-Dienste (Cloud/SaaS) im Beschaffungs-/Freigabeprozess verankern.
- **Technisch:** Cloud-/SaaS-Register führen; Nutzung nicht freigegebener Dienste durch Netzwerk-/Proxy-Kontrollen einschränken (Shadow-IT-Erkennung).
- **Typische Nachweise:** Bewertungsdokumente je Dienst; Freigabeliste; Register.
- **Vorlage:** R02
- **Ressourcen:** ISB + Einkauf/IT; laufend; ggf. CASB/Proxy.
- **AL-Filter:** AL2 + AL3
### 1.3.3-M2 — [MUSS]
**Anforderung:** Externe IT-Dienste sind mit dem Schutzbedarf der verarbeiteten Informationswerte abgestimmt.
- **Organisatorisch:** Schutzbedarf der zu verarbeitenden Daten dem Dienst gegenüberstellen; Eignung dokumentieren.
- **Technisch:** Schutzbedarf/Klassifizierung im Dienstregister mit zulässigen Datenkategorien verknüpfen.
- **Typische Nachweise:** Schutzbedarfs-/Eignungsbewertung je Dienst.
- **Vorlage:** R02
- **Ressourcen:** ISB + Fachbereich; je Dienst.
- **AL-Filter:** AL2 + AL3
### 1.3.3-S1 — [SOLL]
**Anforderung:** Anforderungen an Beschaffung, Inbetriebnahme und Freigabe externer IT-Dienste sind bestimmt und erfüllt.
- **Organisatorisch:** IS-Anforderungen in Beschaffungs-/Onboarding-Checklisten für externe Dienste aufnehmen.
- **Technisch:** Konfigurations-/Sicherheitsvorgaben (z. B. SSO, Verschlüsselung) bei Inbetriebnahme prüfen.
- **Typische Nachweise:** Beschaffungs-/Freigabecheckliste; Inbetriebnahme-Doku.
- **Vorlage:** R02
- **Ressourcen:** Einkauf + IT + ISB; je Dienst.
- **AL-Filter:** AL2 + AL3
### 1.3.3-S2 — [SOLL]
**Anforderung:** Ein Verfahren zur Freigabe unter Berücksichtigung des Schutzbedarfs ist etabliert.
- **Organisatorisch:** Formalen Freigabe-Workflow mit Rollen und Entscheidungskriterien definieren.
- **Technisch:** Freigabe-Workflow im Ticket-/Service-Management abbilden.
- **Typische Nachweise:** dokumentiertes Freigabeverfahren; Freigabetickets.
- **Vorlage:** R02
- **Ressourcen:** ISB + IT; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.3.3-S3 — [SOLL]
**Anforderung:** Externe IT-Dienste und ihre Freigabe sind dokumentiert.
- **Organisatorisch:** Zentrales, aktuelles Register freigegebener Dienste mit Freigabestatus führen.
- **Technisch:** Register im GRC-/Service-Tool mit Freigabehistorie.
- **Typische Nachweise:** Dienstregister mit Freigabestatus.
- **Vorlage:** R02
- **Ressourcen:** ISB; laufend.
- **AL-Filter:** AL2 + AL3
### 1.3.3-S4 — [SOLL]
**Anforderung:** Es wird regelmäßig überprüft, dass nur freigegebene externe IT-Dienste genutzt werden.
- **Organisatorisch:** Periodische Reviews/Abgleich der tatsächlichen Nutzung gegen die Freigabeliste durchführen.
- **Technisch:** Shadow-IT-/CASB-Reports oder Proxy-Logauswertung nutzen.
- **Typische Nachweise:** Review-Protokolle; Shadow-IT-Reports.
- **Vorlage:** R02; VA-15
- **Ressourcen:** IT + ISB; periodisch.
- **AL-Filter:** AL2 + AL3
## Control 1.3.4 — Inwieweit ist sichergestellt, dass nur bewertete und freigegebene Software genutzt wird?
### 1.3.4-M1 — [MUSS]
**Anforderung:** Software wird vor Installation/Nutzung freigegeben; einschlägige Aspekte werden berücksichtigt.
- **Organisatorisch:** Softwarefreigabeprozess (Bewertung Herkunft, Lizenz, Sicherheit) definieren und verpflichtend machen.
- **Technisch:** Application-Whitelisting/Allowlisting und Softwareverteilung über zentrales Endpoint-/Client-Management.
- **Typische Nachweise:** Freigabeliste zugelassener Software; Whitelisting-Konfiguration.
- **Vorlage:** R02
- **Ressourcen:** IT + ISB; ggf. Endpoint-Management/Whitelisting-Tool.
- **AL-Filter:** AL2 + AL3
### 1.3.4-M2 — [MUSS]
**Anforderung:** Die Softwarefreigabe gilt auch für Spezialsoftware wie Wartungswerkzeuge.
- **Organisatorisch:** Wartungs-/Diagnose- und Spezialwerkzeuge explizit in den Freigabeprozess einbeziehen.
- **Technisch:** Kontrollierte Bereitstellung von Wartungssoftware (dedizierte Konten/Systeme, Freigabe je Einsatz).
- **Typische Nachweise:** Freigabeliste inkl. Spezialsoftware; Einsatz-/Freigabedoku.
- **Vorlage:** R02
- **Ressourcen:** IT + ISB; laufend.
- **AL-Filter:** AL2 + AL3
### 1.3.4-S1 — [SOLL]
**Anforderung:** Die zu verwaltenden Softwarearten (Firmware, Betriebssysteme, Anwendungen, Bibliotheken, Gerätetreiber) sind bestimmt.
- **Organisatorisch:** Geltungsbereich des Software-Managements je Softwareart festlegen.
- **Technisch:** Kategorisierung im Software-Inventar/CMDB abbilden.
- **Typische Nachweise:** Übersicht verwalteter Softwarearten.
- **Vorlage:** R02
- **Ressourcen:** IT; gering.
- **AL-Filter:** AL2 + AL3
### 1.3.4-S2 — [SOLL]
**Anforderung:** Repositorys der verwalteten Software existieren.
- **Organisatorisch:** Verbindliche zentrale Software-Quellen definieren.
- **Technisch:** Zentrales Software-Repository/Paketquelle (Distributionspunkt) bereitstellen.
- **Typische Nachweise:** Repository-Übersicht; Verweis auf Distributionspunkt.
- **Vorlage:** R02
- **Ressourcen:** IT; ggf. Repository-Tool.
- **AL-Filter:** AL2 + AL3
### 1.3.4-S3 — [SOLL]
**Anforderung:** Die Software-Repositorys sind gegen unbefugte Manipulation geschützt.
- **Organisatorisch:** Zugriff auf Repositorys nach Least-Privilege regeln; Änderungen protokollieren.
- **Technisch:** Zugriffsschutz, Integritätsprüfung (Signaturen/Hashes), Protokollierung.
- **Typische Nachweise:** Berechtigungskonzept Repository; Integritäts-/Signaturnachweise.
- **Vorlage:** R02; BL-IAM-05
- **Ressourcen:** IT; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.3.4-S4 — [SOLL]
**Anforderung:** Die Freigabe von Software wird regelmäßig überprüft.
- **Organisatorisch:** Periodisches Review der Freigabeliste (weiterhin benötigt/sicher) durchführen.
- **Technisch:** Report aus Software-Inventar/Whitelisting als Reviewgrundlage.
- **Typische Nachweise:** Review-Protokolle der Softwarefreigaben.
- **Vorlage:** R02; VA-15
- **Ressourcen:** IT + ISB; periodisch.
- **AL-Filter:** AL2 + AL3
### 1.3.4-S5 — [SOLL]
**Anforderung:** Softwareversionen und Patch-Stände sind bekannt.
- **Organisatorisch:** Verantwortlichkeit für Versions-/Patchstand-Überblick festlegen.
- **Technisch:** Inventarisierung von Version/Patch via Endpoint-Management/Discovery.
- **Typische Nachweise:** Versions-/Patchstand-Report aus dem Inventar.
- **Vorlage:** R02
- **Ressourcen:** IT; laufend; ggf. Discovery-Tool.
- **AL-Filter:** AL2 + AL3
### 1.3.4-V1 — [SEHR HOCH]
**Anforderung:** Zusätzliche Anforderungen an die Softwarenutzung (z. B. Kontroll-/Überwachungsbedarf) sind, sofern vorhanden, bestimmt. (C, I, A)
- **Organisatorisch:** Für Software mit sehr hohem Schutzbedarf zusätzliche Nutzungs-/Überwachungsauflagen definieren.
- **Technisch:** Erweiterte Protokollierung/Monitoring der Softwarenutzung (z. B. Nutzungslogs, Integritätsüberwachung) umsetzen.
- **Typische Nachweise:** dokumentierte Zusatzanforderungen; Monitoring-/Nutzungsprotokolle.
- **Vorlage:** R02
- **Ressourcen:** IT + ISB; ggf. Monitoring-Erweiterung.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 1.4.1 — Inwieweit werden Informationssicherheitsrisiken gemanagt?
### 1.4.1-M1 — [MUSS]
**Anforderung:** Risikobewertungen werden regelmäßig und anlassbezogen durchgeführt.
- **Organisatorisch:** Turnus (z. B. jährlich) und Anlässe (Änderungen, Vorfälle) für Risikobewertungen festlegen.
- **Technisch:** Risikoregister/GRC-Tool mit Terminierung und Wiedervorlagen.
- **Typische Nachweise:** Risikobewertungsberichte; Zeitplan.
- **Vorlage:** R03; VA-09
- **Ressourcen:** ISB + Risk Owner; periodisch.
- **AL-Filter:** AL2 + AL3
### 1.4.1-M2 — [MUSS]
**Anforderung:** Risiken werden angemessen bewertet (z. B. Eintrittswahrscheinlichkeit und Schadensausmaß).
- **Organisatorisch:** Bewertungsmethodik (Skalen für Wahrscheinlichkeit/Auswirkung) definieren und anwenden.
- **Technisch:** Methodik im GRC-Tool als Bewertungsschema hinterlegen.
- **Typische Nachweise:** bewertete Risiken mit Wahrscheinlichkeit/Auswirkung; Methodenbeschreibung.
- **Vorlage:** R03; VA-09
- **Ressourcen:** ISB; laufend.
- **AL-Filter:** AL2 + AL3
### 1.4.1-M3 — [MUSS]
**Anforderung:** Informationssicherheitsrisiken werden dokumentiert.
- **Organisatorisch:** Vollständige, aktuelle Risikodokumentation sicherstellen.
- **Technisch:** Zentrales Risikoregister im GRC-Tool.
- **Typische Nachweise:** Risikoregister.
- **Vorlage:** R03; VA-09
- **Ressourcen:** ISB; laufend.
- **AL-Filter:** AL2 + AL3
### 1.4.1-M4 — [MUSS]
**Anforderung:** Jedem Risiko ist ein Risk Owner zugeordnet, der für Bewertung und Behandlung verantwortlich ist.
- **Organisatorisch:** Risk Owner je Risiko benennen und Verantwortung kommunizieren.
- **Technisch:** Owner-Feld im Risikoregister pflegen (Pflichtfeld).
- **Typische Nachweise:** Risikoregister mit Owner-Zuordnung.
- **Vorlage:** R03
- **Ressourcen:** ISB + Fachbereiche; gering.
- **AL-Filter:** AL2 + AL3
### 1.4.1-S1 — [SOLL]
**Anforderung:** Ein Verfahren zur Identifikation, Bewertung und Behandlung von Sicherheitsrisiken ist vorhanden.
- **Organisatorisch:** Risikomanagement-Verfahren dokumentieren und freigeben.
- **Technisch:** Verfahren im GRC-Tool/DMS verankern.
- **Typische Nachweise:** freigegebenes Risikomanagement-Verfahren.
- **Vorlage:** R03; VA-09
- **Ressourcen:** ISB; ca. 1–2 PT.
- **AL-Filter:** AL2 + AL3
### 1.4.1-S2 — [SOLL]
**Anforderung:** Kriterien für Bewertung und Behandlung von Sicherheitsrisiken existieren.
- **Organisatorisch:** Akzeptanzkriterien/Risikoappetit und Behandlungskriterien festlegen und freigeben.
- **Technisch:** Kriterien/Schwellenwerte im GRC-Tool hinterlegen.
- **Typische Nachweise:** Kriterienkatalog; Risikoakzeptanzkriterien.
- **Vorlage:** R03
- **Ressourcen:** ISB + Leitung; gering.
- **AL-Filter:** AL2 + AL3
### 1.4.1-S3 — [SOLL]
**Anforderung:** Behandlungsmaßnahmen und Verantwortliche sind festgelegt und dokumentiert; ein Maßnahmenplan wird nachverfolgt.
- **Organisatorisch:** Risikobehandlungsplan mit Maßnahmen, Verantwortlichen und Terminen führen.
- **Technisch:** Maßnahmen-Tracking im GRC-Tool mit Statusverfolgung.
- **Typische Nachweise:** Risikobehandlungsplan; Maßnahmenstatus.
- **Vorlage:** R03
- **Ressourcen:** ISB + Risk Owner; laufend.
- **AL-Filter:** AL2 + AL3
### 1.4.1-S4 — [SOLL]
**Anforderung:** Bei Umfeldänderungen (Organisationsstruktur, Standort, Regularien) erfolgt zeitnah eine Neubewertung.
- **Organisatorisch:** Trigger für anlassbezogene Neubewertung definieren und in Change-Prozesse einbinden.
- **Technisch:** Change-/Ereignis-gekoppelte Erinnerung zur Risiko-Neubewertung.
- **Typische Nachweise:** dokumentierte anlassbezogene Neubewertungen.
- **Vorlage:** R03; VA-09
- **Ressourcen:** ISB; laufend.
- **AL-Filter:** AL2 + AL3
## Control 1.5.1 — Inwieweit wird die Einhaltung von Informationssicherheit überprüft (interne Compliance)?
### 1.5.1-M1 — [MUSS]
**Anforderung:** Die Einhaltung der Richtlinien wird organisationsweit überprüft.
- **Organisatorisch:** Regelmäßige Compliance-Prüfungen/interne Audits über alle Bereiche planen und durchführen.
- **Technisch:** Prüfergebnisse im GRC-Tool erfassen.
- **Typische Nachweise:** Auditplan; Prüf-/Auditberichte.
- **Vorlage:** R03; VA-15
- **Ressourcen:** ISB/Interne Revision; periodisch.
- **AL-Filter:** AL2 + AL3
### 1.5.1-M2 — [MUSS]
**Anforderung:** Richtlinien und Verfahren werden regelmäßig überprüft.
- **Organisatorisch:** Review-Zyklen je Dokument festlegen und nachhalten.
- **Technisch:** Wiedervorlage/Review-Reminder im DMS/GRC.
- **Typische Nachweise:** Review-Historie der Dokumente.
- **Vorlage:** R03; VA-15
- **Ressourcen:** ISB; laufend.
- **AL-Filter:** AL2 + AL3
### 1.5.1-M3 — [MUSS]
**Anforderung:** Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt.
- **Organisatorisch:** Abweichungs-/Maßnahmenmanagement (CAPA) mit Verantwortlichen und Fristen etablieren.
- **Technisch:** Findings/Maßnahmen im GRC-Tool nachverfolgen.
- **Typische Nachweise:** Maßnahmenliste zu Findings; Statusnachverfolgung.
- **Vorlage:** R03; VA-15
- **Ressourcen:** ISB + Fachbereiche; laufend.
- **AL-Filter:** AL2 + AL3
### 1.5.1-M4 — [MUSS]
**Anforderung:** Die Einhaltung von IS-Anforderungen (z. B. technische Vorgaben) wird regelmäßig überprüft.
- **Organisatorisch:** Technische Compliance-Prüfungen (Konfiguration/Baseline-Konformität) planen.
- **Technisch:** Automatisierte Compliance-/Konfigurations-Scans gegen Baseline-Vorgaben (BL-*).
- **Typische Nachweise:** Scan-/Konformitätsberichte; Abweichungslisten.
- **Vorlage:** R03; VA-15
- **Ressourcen:** IT + ISB; ggf. Compliance-Scan-Tool.
- **AL-Filter:** AL2 + AL3
### 1.5.1-M5 — [MUSS]
**Anforderung:** Ergebnisse der Überprüfungen werden aufgezeichnet und aufbewahrt.
- **Organisatorisch:** Aufbewahrungsfristen für Prüfergebnisse festlegen.
- **Technisch:** Revisionssichere Ablage der Berichte im DMS/GRC.
- **Typische Nachweise:** archivierte Prüfberichte; Ablage-/Aufbewahrungsnachweis.
- **Vorlage:** R03; VA-15
- **Ressourcen:** ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.5.1-S1 — [SOLL]
**Anforderung:** Ein Plan für Inhalt und Rahmenbedingungen (Zeitplan, Umfang, Controls) der Überprüfungen liegt vor.
- **Organisatorisch:** Mehrjahres-/Jahresauditplan mit Scope und Terminen erstellen und freigeben.
- **Technisch:** Auditplan im GRC-Tool mit Terminplanung.
- **Typische Nachweise:** freigegebener Prüf-/Auditplan.
- **Vorlage:** R03; VA-15
- **Ressourcen:** ISB; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
## Control 1.5.2 — Inwieweit wird die Informationssicherheit durch unabhängige Stellen überprüft?
### 1.5.2-M1 — [MUSS]
**Anforderung:** IS-Überprüfungen werden durch eine unabhängige und kompetente Stelle regelmäßig und nach grundlegenden Änderungen durchgeführt.
- **Organisatorisch:** Unabhängige Prüfinstanz (interne Revision oder externer Prüfer) beauftragen; Unabhängigkeit sicherstellen; Turnus/Anlässe festlegen.
- **Technisch:** Prüfergebnisse zentral im GRC-Tool dokumentieren.
- **Typische Nachweise:** unabhängige Prüf-/Auditberichte; Beauftragung/Unabhängigkeitsnachweis.
- **Vorlage:** R03; VA-15
- **Ressourcen:** ISB + interne Revision/externer Auditor; Prüfbudget möglich.
- **AL-Filter:** AL2 + AL3
### 1.5.2-M2 — [MUSS]
**Anforderung:** Maßnahmen zur Korrektur möglicher Abweichungen werden eingeleitet und verfolgt.
- **Organisatorisch:** Findings der unabhängigen Prüfung in das Maßnahmenmanagement überführen und nachhalten.
- **Technisch:** Maßnahmen-Tracking im GRC-Tool.
- **Typische Nachweise:** Maßnahmenliste zu Prüf-Findings; Statusnachverfolgung.
- **Vorlage:** R03; VA-15
- **Ressourcen:** ISB + Fachbereiche; laufend.
- **AL-Filter:** AL2 + AL3
### 1.5.2-S1 — [SOLL]
**Anforderung:** Ergebnisse der Überprüfungen werden dokumentiert und der Organisationsleitung berichtet.
- **Organisatorisch:** Berichtsweg an die Leitung (z. B. im Management-Review) etablieren.
- **Technisch:** Berichte/Reportings im GRC-Tool bereitstellen.
- **Typische Nachweise:** Prüfbericht mit Leitungsvorlage; Management-Review-Protokoll.
- **Vorlage:** R03; VA-15
- **Ressourcen:** ISB; gering, periodisch.
- **AL-Filter:** AL2 + AL3
## Control 1.6.1 — Inwieweit werden Sicherheitsereignisse gemeldet?
### 1.6.1-M1 — [MUSS]
**Anforderung:** Eine Definition für ein meldepflichtiges Sicherheitsereignis/eine Beobachtung existiert und ist bekannt.
- **Organisatorisch:** Definition und Beispiele meldepflichtiger Ereignisse festlegen und kommunizieren.
- **Technisch:** Definition im Intranet/Meldeportal verfügbar machen.
- **Typische Nachweise:** dokumentierte Definition; Kommunikations-/Schulungsnachweis.
- **Vorlage:** R04; VA-01
- **Ressourcen:** ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.1-M2 — [MUSS]
**Anforderung:** Angemessene, risikoorientierte Meldemechanismen sind definiert, umgesetzt und bekannt.
- **Organisatorisch:** Meldeprozess und -wege definieren und einführen; Bekanntmachung sicherstellen.
- **Technisch:** Meldekanäle bereitstellen (Ticketsystem, Meldeportal, Hotline/E-Mail).
- **Typische Nachweise:** beschriebener Meldeprozess; eingerichtete Meldekanäle; Kommunikation.
- **Vorlage:** R04; VA-01
- **Ressourcen:** ISB + IT; ggf. Ticket-/Meldetool.
- **AL-Filter:** AL2 + AL3
### 1.6.1-M3 — [MUSS]
**Anforderung:** Angemessene Kanäle zur Kommunikation mit Meldenden existieren.
- **Organisatorisch:** Rückkanäle für Rückfragen/Statusinformation an Meldende festlegen.
- **Technisch:** Kommunikationsfunktion im Ticketsystem (Rückmeldungen, Status).
- **Typische Nachweise:** Kommunikationsverlauf im Ticketsystem; Kanalbeschreibung.
- **Vorlage:** R04
- **Ressourcen:** IT + ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.1-S1 — [SOLL]
**Anforderung:** Eine gemeinsame Anlaufstelle für die Ereignismeldung existiert.
- **Organisatorisch:** Single Point of Contact (z. B. Security-Postfach/Service Desk) benennen.
- **Technisch:** Zentrale Meldeadresse/-portal einrichten.
- **Typische Nachweise:** SPoC-Beschreibung; zentrale Meldeadresse.
- **Vorlage:** R04
- **Ressourcen:** ISB + IT; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.1-S2 — [SOLL]
**Anforderung:** Verschiedene Meldekanäle je nach Schwere (Echtzeit für Notfälle, asynchron via Ticket/E-Mail) sind verfügbar.
- **Organisatorisch:** Kanäle nach Schweregrad differenzieren (Hotline vs. Ticket) und kommunizieren.
- **Technisch:** Hotline/Notfallnummer plus asynchrone Kanäle (Ticket, E-Mail) bereitstellen.
- **Typische Nachweise:** Kanalübersicht nach Schweregrad.
- **Vorlage:** R04
- **Ressourcen:** IT + ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.1-S3 — [SOLL]
**Anforderung:** Beschäftigte sind verpflichtet und geschult, relevante Ereignisse zu melden.
- **Organisatorisch:** Meldepflicht in Richtlinien/Verpflichtung verankern; Schulung/Sensibilisierung durchführen.
- **Technisch:** Schulungsnachweise im Schulungssystem dokumentieren.
- **Typische Nachweise:** Verpflichtung; Schulungs-/Awareness-Nachweise.
- **Vorlage:** R04; VA-12
- **Ressourcen:** ISB + HR; laufend.
- **AL-Filter:** AL2 + AL3
### 1.6.1-S4 — [SOLL]
**Anforderung:** Sicherheitsereignisse können auch durch Externe gemeldet werden; einschlägige Aspekte werden berücksichtigt.
- **Organisatorisch:** Externen Meldeweg definieren und kommunizieren (Lieferanten, Kunden, Öffentlichkeit).
- **Technisch:** Öffentlich erreichbare Meldeadresse/-formular (ggf. security.txt/Kontaktseite).
- **Typische Nachweise:** externe Kontakt-/Meldemöglichkeit; Prozessbeschreibung.
- **Vorlage:** R04
- **Ressourcen:** ISB + IT; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.1-S5 — [SOLL]
**Anforderung:** Mechanismus und Information zur Meldung sind für alle relevanten Meldenden zugänglich.
- **Organisatorisch:** Zugänglichkeit der Meldeinformation für alle Zielgruppen sicherstellen.
- **Technisch:** Meldeinformationen an zentralen, jederzeit erreichbaren Stellen (Intranet, Portal) veröffentlichen.
- **Typische Nachweise:** veröffentlichte Meldeanleitung; Zugriffsnachweis.
- **Vorlage:** R04
- **Ressourcen:** ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.1-S6 — [SOLL]
**Anforderung:** Ein Rückmeldeverfahren an die Meldenden ist etabliert.
- **Organisatorisch:** Feedback-/Statusrückmeldung an Meldende verbindlich festlegen.
- **Technisch:** Automatische Eingangs-/Statusbenachrichtigung im Ticketsystem.
- **Typische Nachweise:** Rückmeldungen/Benachrichtigungen; Prozessbeschreibung.
- **Vorlage:** R04
- **Ressourcen:** IT + ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.1-V1 — [SEHR HOCH]
**Anforderung:** Tests und Übungen der Ereignis- und Beobachtungsmeldung werden regelmäßig durchgeführt. (C, I, A)
- **Organisatorisch:** Regelmäßige Meldeübungen (z. B. Phishing-Simulation, Testmeldungen) planen und auswerten.
- **Technisch:** Simulations-/Testmeldungen über die Meldekanäle auslösen und Ergebnisse auswerten.
- **Typische Nachweise:** Übungsplan; Übungs-/Auswertungsberichte.
- **Vorlage:** R04; VA-01
- **Ressourcen:** ISB; periodisch; ggf. Awareness-/Simulationstool.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 1.6.2 — Inwieweit werden gemeldete Sicherheitsereignisse gemanagt?
### 1.6.2-M1 — [MUSS]
**Anforderung:** Gemeldete Ereignisse werden ohne unangemessene Verzögerung bearbeitet.
- **Organisatorisch:** Bearbeitungsprozess mit Erstreaktion und Verantwortlichen definieren.
- **Technisch:** Ticket-/Incident-Workflow mit Eingangs- und Bearbeitungsstatus.
- **Typische Nachweise:** Incident-Tickets mit Zeitstempeln; Prozessbeschreibung.
- **Vorlage:** R04; VA-01
- **Ressourcen:** ISB/Incident-Team; laufend.
- **AL-Filter:** AL2 + AL3
### 1.6.2-M2 — [MUSS]
**Anforderung:** Eine angemessene Reaktion auf gemeldete Sicherheitsereignisse ist sichergestellt.
- **Organisatorisch:** Reaktions-/Behandlungsverfahren (Analyse, Eindämmung, Behebung) festlegen.
- **Technisch:** Incident-Response-Workflow und ggf. Playbooks im Tool hinterlegen.
- **Typische Nachweise:** dokumentierte Vorfallbehandlung; Abschluss-/Behebungsnachweis.
- **Vorlage:** R04; VA-01
- **Ressourcen:** Incident-Team; laufend.
- **AL-Filter:** AL2 + AL3
### 1.6.2-M3 — [MUSS]
**Anforderung:** Lessons Learned fließen in die kontinuierliche Verbesserung ein.
- **Organisatorisch:** Nachbereitung (Post-Incident-Review) mit Ableitung von Verbesserungen durchführen.
- **Technisch:** Verbesserungsmaßnahmen im GRC-/Maßnahmentool nachverfolgen.
- **Typische Nachweise:** Lessons-Learned-/Post-Incident-Protokolle; abgeleitete Maßnahmen.
- **Vorlage:** R04
- **Ressourcen:** ISB + Incident-Team; je Vorfall.
- **AL-Filter:** AL2 + AL3
### 1.6.2-S1 — [SOLL]
**Anforderung:** Gemeldete Ereignisse werden kategorisiert, qualifiziert und priorisiert.
- **Organisatorisch:** Kategorien, Qualifizierungen und Prioritätsstufen definieren und anwenden.
- **Technisch:** Klassifizierungsfelder/Priorisierung im Ticket-/Incident-System.
- **Typische Nachweise:** kategorisierte/priorisierte Tickets; Klassifizierungsschema.
- **Vorlage:** R04; VA-01
- **Ressourcen:** Incident-Team; laufend.
- **AL-Filter:** AL2 + AL3
### 1.6.2-S2 — [SOLL]
**Anforderung:** Verantwortlichkeiten für die Behandlung je Kategorie sind definiert und zugewiesen.
- **Organisatorisch:** Zuständigkeiten je Ereigniskategorie festlegen (RACI/Eskalationsmatrix).
- **Technisch:** Zuweisungsregeln im Ticketsystem (Routing/Queues).
- **Typische Nachweise:** Zuständigkeitsmatrix; Ticket-Routing-Konfiguration.
- **Vorlage:** R04; VA-01
- **Ressourcen:** ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.2-S3 — [SOLL]
**Anforderung:** Eine Strategie zur Meldung potenziell strafrechtlich relevanter Aspekte an Behörden existiert. (C, I, A)
- **Organisatorisch:** Vorgehen und Zuständigkeit für Behördenmeldungen (Legal/Datenschutz einbinden) festlegen.
- **Technisch:** Kontaktinformationen/Vorlagen im Incident-Prozess hinterlegen.
- **Typische Nachweise:** dokumentierte Meldestrategie; Behördenkontaktliste.
- **Vorlage:** R04
- **Ressourcen:** ISB + Legal; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.2-H1 — [HOCH]
**Anforderung:** Maximale Reaktionszeiten je Klasse, Kategorie und Schwere sind definiert. (C, I, A)
- **Organisatorisch:** SLA/Reaktionszeiten je Priorität/Kategorie festlegen und freigeben.
- **Technisch:** SLA-Zeiten und Timer/Eskalation im Ticketsystem konfigurieren.
- **Typische Nachweise:** SLA-Matrix; SLA-Konfiguration im Tool.
- **Vorlage:** R04
- **Ressourcen:** ISB + IT; ca. 1 PT.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.2-H2 — [HOCH]
**Anforderung:** Nicht prioritätsgerecht bearbeitete Ereignisse werden eskaliert; einschlägige Aspekte werden berücksichtigt. (C, I, A)
- **Organisatorisch:** Eskalationswege und -stufen definieren.
- **Technisch:** Automatische SLA-Eskalation bei Fristüberschreitung im Ticketsystem.
- **Typische Nachweise:** Eskalationskonzept; dokumentierte Eskalationen.
- **Vorlage:** R04
- **Ressourcen:** IT + ISB; ca. 1 PT.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.2-H3 — [HOCH]
**Anforderung:** Gesetzliche, regulatorische und vertragliche Meldepflichten sowie Kontaktinformationen sind bekannt. (C, I, A)
- **Organisatorisch:** Meldepflichten (z. B. Datenschutz, Kundenverträge) mit Fristen und Kontakten zusammenstellen.
- **Technisch:** Melderegister/Kontaktliste im Incident-Prozess bereitstellen.
- **Typische Nachweise:** Melderegister; Kontaktliste; Vertrags-/Rechtsbezug.
- **Vorlage:** R04
- **Ressourcen:** ISB + Legal; ca. 1 PT.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.2-H4 — [HOCH]
**Anforderung:** Eine Kommunikationsstrategie für sicherheitsrelevante Ereignisse existiert; einschlägige Aspekte werden berücksichtigt. (C, I, A)
- **Organisatorisch:** Interne/externe Kommunikationsstrategie (Sprecher, Zielgruppen, Freigaben) definieren.
- **Technisch:** Kommunikationsvorlagen/Verteiler hinterlegen.
- **Typische Nachweise:** Kommunikationsstrategie/-plan; Vorlagen.
- **Vorlage:** R04
- **Ressourcen:** ISB + Kommunikation; ca. 1 PT.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.2-H5 — [HOCH]
**Anforderung:** Verfahren zur Reaktion auf Sicherheitsvorfälle bei Lieferanten sind etabliert; einschlägige Aspekte werden berücksichtigt. (C, I, A)
- **Organisatorisch:** Meldepflichten und Reaktionsprozesse mit Lieferanten vertraglich vereinbaren und im Incident-Prozess berücksichtigen.
- **Technisch:** Lieferanten-Kontakte/Schnittstellen im Incident-Tool erfassen.
- **Typische Nachweise:** Lieferanten-Vorfallverfahren; vertragliche Meldeklauseln.
- **Vorlage:** R04; VA-01
- **Ressourcen:** ISB + Einkauf; ca. 1 PT.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.2-V1 — [SEHR HOCH]
**Anforderung:** Die Behandlung von Ereignissen unterschiedlicher Kategorien und Prioritäten wird regelmäßig getestet; einschlägige Aspekte werden berücksichtigt. (A)
- **Organisatorisch:** Regelmäßige Incident-Response-Übungen über verschiedene Kategorien/Prioritäten planen und auswerten.
- **Technisch:** Testszenarien über den Incident-Workflow durchspielen; Ergebnisse dokumentieren.
- **Typische Nachweise:** Übungsplan; Übungs-/Testberichte.
- **Vorlage:** R04; VA-01
- **Ressourcen:** ISB + Incident-Team; periodisch.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 1.6.3 — Inwieweit werden Krisen gemanagt?
### 1.6.3-M1 — [MUSS]
**Anforderung:** Ein angemessener Plan zur Reaktion auf und Bewältigung von Krisensituationen existiert; erforderliche Ressourcen sind verfügbar.
- **Organisatorisch:** Krisenmanagementplan mit Rollen, Abläufen und Ressourcen erstellen und freigeben.
- **Technisch:** Plan und Kontaktdaten redundant/offline verfügbar halten.
- **Typische Nachweise:** freigegebener Krisenmanagementplan; Ressourcenübersicht.
- **Vorlage:** R04; VA-02
- **Ressourcen:** ISB + Leitung; ca. 2–3 PT.
- **AL-Filter:** AL2 + AL3
### 1.6.3-M2 — [MUSS]
**Anforderung:** Verantwortlichkeiten und Befugnisse für das Krisenmanagement sind definiert, dokumentiert und zugewiesen.
- **Organisatorisch:** Krisenrollen und Entscheidungsbefugnisse festlegen und namentlich zuweisen.
- **Technisch:** Rollen-/Kontaktverzeichnis im Krisenplan hinterlegen.
- **Typische Nachweise:** Rollen-/Befugnismatrix; Krisenorganigramm.
- **Vorlage:** R04
- **Ressourcen:** Leitung + ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.3-M3 — [MUSS]
**Anforderung:** Die verantwortlichen Beschäftigten sind definiert und für ihre Aufgabe qualifiziert.
- **Organisatorisch:** Qualifikation der Krisenverantwortlichen sicherstellen (Schulung/Training).
- **Technisch:** Qualifikations-/Trainingsnachweise dokumentieren.
- **Typische Nachweise:** Benennungen; Schulungs-/Trainingsnachweise.
- **Vorlage:** R04; VA-12
- **Ressourcen:** HR + ISB; Schulungsbudget.
- **AL-Filter:** AL2 + AL3
### 1.6.3-S1 — [SOLL]
**Anforderung:** Methoden zur Erkennung von Krisensituationen sind etabliert; Anzeichen und vorhersehbare Krisen sind identifiziert.
- **Organisatorisch:** Frühwarnindikatoren und Erkennungskriterien definieren.
- **Technisch:** Monitoring/Meldeschwellen zur Krisenerkennung einbinden.
- **Typische Nachweise:** Indikatoren-/Erkennungskatalog.
- **Vorlage:** R04; VA-02
- **Ressourcen:** ISB; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.6.3-S2 — [SOLL]
**Anforderung:** Ein Verfahren zur Auslösung und/oder Eskalation des Krisenmanagements ist vorhanden.
- **Organisatorisch:** Alarmierungs-/Eskalationsverfahren mit Auslösekriterien festlegen.
- **Technisch:** Alarmierungsweg/-tool (Notfallbenachrichtigung) bereitstellen.
- **Typische Nachweise:** Alarmierungs-/Eskalationsverfahren.
- **Vorlage:** R04
- **Ressourcen:** ISB; ggf. Alarmierungstool.
- **AL-Filter:** AL2 + AL3
### 1.6.3-S3 — [SOLL]
**Anforderung:** Strategische Ziele und ihre Priorität in Krisensituationen sind definiert und bekannt.
- **Organisatorisch:** Krisenziele und Prioritäten (z. B. Schutz von Leben, Kernprozessen) festlegen und kommunizieren.
- **Technisch:** Ziele im Krisenplan dokumentieren.
- **Typische Nachweise:** dokumentierte Krisenziele/Prioritäten.
- **Vorlage:** R04
- **Ressourcen:** Leitung + ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.3-S4 — [SOLL]
**Anforderung:** Ein Krisenstab ist definiert und genehmigt.
- **Organisatorisch:** Zusammensetzung, Aufgaben und Stellvertretung des Krisenstabs festlegen und genehmigen.
- **Technisch:** Krisenstab-Kontaktliste redundant vorhalten.
- **Typische Nachweise:** genehmigte Krisenstab-Definition; Besetzungsliste.
- **Vorlage:** R04
- **Ressourcen:** Leitung + ISB; gering.
- **AL-Filter:** AL2 + AL3
### 1.6.3-S5 — [SOLL]
**Anforderung:** Krisenrichtlinien und -verfahren sind definiert und genehmigt.
- **Organisatorisch:** Krisenrichtlinien/-verfahren dokumentieren und freigeben.
- **Technisch:** Verfahren im DMS und offline verfügbar halten.
- **Typische Nachweise:** freigegebene Krisenrichtlinien/-verfahren.
- **Vorlage:** R04; VA-02
- **Ressourcen:** ISB; ca. 1 PT.
- **AL-Filter:** AL2 + AL3
### 1.6.3-S6 — [SOLL]
**Anforderung:** Die Krisenplanung wird regelmäßig überprüft und aktualisiert.
- **Organisatorisch:** Review-Zyklus für die Krisenplanung festlegen.
- **Technisch:** Wiedervorlage/Review-Reminder im DMS.
- **Typische Nachweise:** Review-Historie der Krisenplanung.
- **Vorlage:** R04; VA-15
- **Ressourcen:** ISB; gering, periodisch.
- **AL-Filter:** AL2 + AL3
### 1.6.3-H1 — [HOCH]
**Anforderung:** Relevante unterschiedliche potenzielle Krisenszenarien sind identifiziert.
- **Organisatorisch:** Szenarienkatalog (z. B. Ausfall, Cyberangriff, Standortverlust) erstellen.
- **Technisch:** Szenarien im Krisenplan/BCM-Tool dokumentieren.
- **Typische Nachweise:** Krisenszenarien-Katalog.
- **Vorlage:** R04; VA-02
- **Ressourcen:** ISB; ca. 1 PT.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.3-H2 — [HOCH]
**Anforderung:** Notwendige Ressourcen und Informationen zur Krisenbewältigung sind identifiziert; Maßnahmen zur Sicherstellung der Verfügbarkeit/Ausfallplanung sind vorhanden. (A)
- **Organisatorisch:** Kritische Ressourcen (Kommunikation, Kontakt-/Risikoinfos) bestimmen und Ausfallplanung erstellen.
- **Technisch:** Redundante Kommunikationsinfrastruktur; Offline-Verfügbarkeit von Kontakt-/Risikoinformationen; Backup (BL-OPS-05).
- **Typische Nachweise:** Ressourcenliste; Ausfall-/Redundanzkonzept.
- **Vorlage:** R04; BL-OPS-05
- **Ressourcen:** ISB + IT; ggf. Beschaffung Redundanz.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.3-H3 — [HOCH]
**Anforderung:** Eine Kommunikationsstrategie für Krisensituationen existiert. (A)
- **Organisatorisch:** Krisenkommunikationsstrategie (interne/externe Zielgruppen, Sprecher, Freigaben) definieren.
- **Technisch:** Kommunikationskanäle/-vorlagen und redundante Erreichbarkeit bereitstellen.
- **Typische Nachweise:** Krisenkommunikationsplan; Vorlagen/Verteiler.
- **Vorlage:** R04
- **Ressourcen:** ISB + Kommunikation; ca. 1 PT.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.3-H4 — [HOCH]
**Anforderung:** Effizienz, Durchführbarkeit und Angemessenheit der Krisenplanung werden regelmäßig bewertet. (A)
- **Organisatorisch:** Bewertungskriterien und Turnus zur Beurteilung der Krisenplanung festlegen.
- **Technisch:** Bewertungsergebnisse dokumentieren und Maßnahmen ableiten.
- **Typische Nachweise:** Bewertungsberichte der Krisenplanung.
- **Vorlage:** R04; VA-15
- **Ressourcen:** ISB; periodisch.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.3-H5 — [HOCH]
**Anforderung:** Stichprobenbasierte Tests der Krisenplanung werden durchgeführt (z. B. Simulation, Tabletop-Übungen mit Schlüsselpersonal). (A)
- **Organisatorisch:** Tabletop-/Simulationsübungen mit Schlüsselpersonal planen und auswerten.
- **Technisch:** Übungsszenarien vorbereiten; Ergebnisse dokumentieren.
- **Typische Nachweise:** Übungsplan; Übungs-/Auswertungsberichte.
- **Vorlage:** R04; VA-02
- **Ressourcen:** ISB + Krisenstab; periodisch.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 1.6.3-V1 — [SEHR HOCH]
**Anforderung:** Krisenübungen und Simulationen unter Einbindung aller relevanten Personen einschließlich Entscheidungsträger werden regelmäßig durchgeführt. (A)
- **Organisatorisch:** Umfassende Krisenübungen mit Leitung/Entscheidungsträgern regelmäßig durchführen und nachbereiten.
- **Technisch:** Realitätsnahe Simulationsumgebung/-szenarien inkl. Kommunikationsinfrastruktur einsetzen.
- **Typische Nachweise:** Übungskonzept; Teilnahmenachweise (inkl. Leitung); Auswertungs-/Verbesserungsberichte.
- **Vorlage:** R04; VA-02
- **Ressourcen:** ISB + Leitung + Krisenstab; periodisch; ggf. externe Übungsbegleitung.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
---
# Kapitel 2–4 — Personal, Physisch, IAM
## Control 2.1.1 — Qualifikation und Eignung des Personals
### 2.1.1-M1 — [MUSS]
**Anforderung:** Sensible Arbeitsbereiche und Tätigkeiten sind bestimmt.
- **Organisatorisch:** Sensible Bereiche/Tätigkeiten (z. B. Administration, Zugang zu Kundennetzen, Fertigung mit Prototypenbezug) in einer Übersicht definieren und den Stellenprofilen zuordnen; Kriterien mit HR und Fachbereichen abstimmen.
- **Technisch:** Zuordnung in der HR-/Berechtigungssystematik hinterlegen, sodass sensible Rollen an erhöhte Prüf- und Berechtigungsanforderungen gekoppelt sind (BL-IAM-04 Rollenmodell).
- **Typische Nachweise:** Liste sensibler Arbeitsbereiche/Tätigkeiten, Stellenprofile mit Sensibilitätskennzeichnung, Freigabevermerk HR/ISB.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR + ISB, gering; einmalige Erhebung, danach Pflege im Onboarding.
- **AL-Filter:** AL2, AL3
### 2.1.1-M2 — [MUSS]
**Anforderung:** Die Anforderungen an Beschäftigte hinsichtlich ihrer Stellenprofile sind bestimmt und erfüllt.
- **Organisatorisch:** Je Stellenprofil erforderliche Qualifikationen, Sicherheitsanforderungen und Nachweispflichten definieren und im Einstellungsprozess prüfen.
- **Technisch:** Anforderungsprofile im HR-System/Recruiting-Tool als strukturierte Felder pflegen; Abgleich bei Besetzung dokumentieren.
- **Typische Nachweise:** Stellenbeschreibungen mit Sicherheitsanforderungen, Nachweis der Anforderungsprüfung im Einstellungsakt.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR, gering–mittel; laufend im Recruiting.
- **AL-Filter:** AL2, AL3
### 2.1.1-M3 — [MUSS]
**Anforderung:** Die Identität potenzieller Beschäftigter wird verifiziert (z. B. Prüfung von Ausweisdokumenten).
- **Organisatorisch:** Verbindliche Identitätsprüfung (amtliches Ausweisdokument) als Pflichtschritt im Onboarding festlegen; Ergebnis revisionssicher vermerken (ohne unzulässige Kopien).
- **Technisch:** Prüfvermerk im HR-System dokumentieren; ggf. Identverfahren des Dienstleisters nutzen.
- **Typische Nachweise:** Onboarding-Checkliste mit Feld „Identität geprüft", Prüfvermerk, Prozessbeschreibung.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR, gering; je Einstellung.
- **AL-Filter:** AL2, AL3
### 2.1.1-S1 — [SOLL]
**Anforderung:** Die persönliche Eignung potenzieller Beschäftigter wird mit einfachen Methoden überprüft (z. B. Vorstellungsgespräch).
- **Organisatorisch:** Strukturiertes Vorstellungsgespräch mit Eignungsbewertung als Standardschritt etablieren; Bewertungsraster verwenden.
- **Technisch:** Bewertung im Recruiting-Tool dokumentieren.
- **Typische Nachweise:** Interviewleitfaden, dokumentierte Eignungsbewertung.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR/Fachbereich, gering.
- **AL-Filter:** AL2, AL3
### 2.1.1-S2 — [SOLL]
**Anforderung:** Eine erweiterte Eignungsprüfung abhängig vom Arbeitsbereich wird durchgeführt (z. B. Referenzen, Zeugnisse, Führungszeugnis).
- **Organisatorisch:** Für sensible Tätigkeiten (aus M1) erweiterte Prüfschritte festlegen (Referenz-/Zeugnisprüfung, Führungszeugnis) unter Beachtung arbeits- und datenschutzrechtlicher Grenzen.
- **Technisch:** Prüfumfang je Sensibilitätsstufe im HR-System hinterlegen; Nachweise fristgerecht und datensparsam ablegen.
- **Typische Nachweise:** Prüfkonzept nach Sensibilitätsstufe, dokumentierte Referenz-/Zeugnisprüfung, Vermerk Führungszeugnis.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR + Datenschutz, mittel; nur für sensible Rollen.
- **AL-Filter:** AL2, AL3
## Control 2.1.2 — Verpflichtung der Beschäftigten
### 2.1.2-M1 — [MUSS]
**Anforderung:** Eine Vertraulichkeitsverpflichtung ist in Kraft.
- **Organisatorisch:** Vertraulichkeitsverpflichtung (NDA/Verschwiegenheit) verpflichtend bei Eintritt unterzeichnen lassen; Nachhalten der Unterschriften.
- **Technisch:** Signierte Verpflichtungen im Personalakten-/DMS-System ablegen; Status je Beschäftigtem nachvollziehbar.
- **Typische Nachweise:** Unterzeichnete Vertraulichkeitsverpflichtungen, Vollständigkeitsübersicht.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR, gering; je Eintritt.
- **AL-Filter:** AL2, AL3
### 2.1.2-M2 — [MUSS]
**Anforderung:** Eine Verpflichtung zur Einhaltung der Informationssicherheitsrichtlinien ist in Kraft.
- **Organisatorisch:** Verpflichtung zur Einhaltung der IS-Richtlinien in Arbeitsvertrag oder gesonderte Erklärung aufnehmen; bei Richtlinienänderung erneut bestätigen lassen.
- **Technisch:** Bestätigung über HR-Portal/LMS mit Zeitstempel erfassen.
- **Typische Nachweise:** Unterzeichnete Verpflichtungserklärung, Zustimmungsprotokoll im Portal.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR, gering.
- **AL-Filter:** AL2, AL3
### 2.1.2-S1 — [SOLL]
**Anforderung:** Eine über den Arbeitsvertrag hinausgehende Vertraulichkeitsverpflichtung ist in Kraft.
- **Organisatorisch:** Für Rollen mit Zugang zu hoch klassifizierten oder Kundeninformationen ergänzende NDAs (auch nachvertraglich) vorsehen.
- **Technisch:** Zuordnung erweiterter NDAs zu sensiblen Rollen im HR-System.
- **Typische Nachweise:** Ergänzende NDA-Vorlage, unterzeichnete Zusatzvereinbarungen.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR + Recht, gering.
- **AL-Filter:** AL2, AL3
### 2.1.2-S2 — [SOLL]
**Anforderung:** Informationssicherheitsaspekte werden in den Arbeitsverträgen der Beschäftigten berücksichtigt.
- **Organisatorisch:** Standard-IS-Klauseln (Geheimhaltung, Richtlinientreue, Rückgabepflichten, Konsequenzen) mit HR/Recht in Vertragsmuster verankern.
- **Technisch:** Zentrale Vertragsvorlagen im DMS versionieren.
- **Typische Nachweise:** Vertragsmuster mit IS-Klauseln, Freigabe Recht.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR + Recht, gering; einmalig.
- **AL-Filter:** AL2, AL3
### 2.1.2-S3 — [SOLL]
**Anforderung:** Ein Verfahren zum Umgang mit Verstößen gegen diese Verpflichtungen ist beschrieben.
- **Organisatorisch:** Eskalations- und Sanktionsprozess (Disziplinarmaßnahmen) mit HR, Betriebsrat und Recht definieren und kommunizieren.
- **Technisch:** Fälle im HR-/Vorfallsystem nachvollziehbar dokumentieren.
- **Typische Nachweise:** Verfahrensbeschreibung Verstöße, Sanktionskatalog, ggf. dokumentierte Fälle.
- **Vorlage:** R05; VA-14
- **Ressourcen:** HR + Recht, gering; einmalig, danach anlassbezogen.
- **AL-Filter:** AL2, AL3
## Control 2.1.3 — Sensibilisierung und Schulung
### 2.1.3-M1 — [MUSS]
**Anforderung:** Beschäftigte werden geschult und sensibilisiert.
- **Organisatorisch:** Verpflichtende IS-Awareness-Schulung bei Eintritt und mindestens jährlich; Teilnahme nachhalten und mahnen.
- **Technisch:** Schulungsdurchführung und -nachweis über LMS/Awareness-Plattform, inkl. Erinnerungen.
- **Typische Nachweise:** Schulungsnachweise/Teilnahmequote, Schulungsinhalte, Einladungs-/Mahnprotokolle.
- **Vorlage:** R05; VA-12
- **Ressourcen:** ISB + HR, mittel; Plattform ggf. zu beschaffen (Awareness-Tool) — führt zu Aufgabe.
- **AL-Filter:** AL2, AL3
### 2.1.3-S1 — [SOLL]
**Anforderung:** Ein Konzept für Sensibilisierung und Schulung der Beschäftigten ist erstellt.
- **Organisatorisch:** Awareness-Konzept mit Zielen, Inhalten, Turnus, Formaten und Erfolgskontrolle dokumentieren.
- **Technisch:** Konzept im DMS versionieren; Kennzahlen aus dem LMS ableiten.
- **Typische Nachweise:** Awareness-/Schulungskonzept, Jahresplan.
- **Vorlage:** R05; VA-12
- **Ressourcen:** ISB, gering–mittel; einmalig, jährliche Fortschreibung.
- **AL-Filter:** AL2, AL3
### 2.1.3-S2 — [SOLL]
**Anforderung:** Zielgruppen für Schulungs- und Sensibilisierungsmaßnahmen sind identifiziert und im Konzept berücksichtigt.
- **Organisatorisch:** Zielgruppen (Führungskräfte, Administratoren, Beschäftigte mit Kundennetzzugang, Fertigung) mit spezifischen Inhalten definieren.
- **Technisch:** Zielgruppen-Zuordnung und differenzierte Lernpfade im LMS abbilden.
- **Typische Nachweise:** Zielgruppenmatrix, rollenspezifische Curricula.
- **Vorlage:** R05; VA-12
- **Ressourcen:** ISB, gering.
- **AL-Filter:** AL2, AL3
### 2.1.3-S3 — [SOLL]
**Anforderung:** Das Konzept ist durch die verantwortliche Leitung genehmigt.
- **Organisatorisch:** Formale Freigabe des Awareness-Konzepts durch die Leitung einholen und dokumentieren.
- **Technisch:** Freigabevermerk/Signatur im DMS.
- **Typische Nachweise:** Freigabeprotokoll/Managementunterschrift.
- **Vorlage:** R05; VA-12
- **Ressourcen:** Leitung + ISB, gering.
- **AL-Filter:** AL2, AL3
### 2.1.3-S4 — [SOLL]
**Anforderung:** Schulungs- und Sensibilisierungsmaßnahmen werden regelmäßig und anlassbezogen durchgeführt.
- **Organisatorisch:** Jahresturnus plus anlassbezogene Maßnahmen (z. B. nach Vorfällen, neuen Bedrohungen) festlegen.
- **Technisch:** Kampagnen (z. B. Phishing-Simulation) und Turnusschulungen über die Awareness-Plattform steuern.
- **Typische Nachweise:** Durchführungsnachweise, Kampagnenauswertungen.
- **Vorlage:** R05; VA-12
- **Ressourcen:** ISB, mittel; laufend.
- **AL-Filter:** AL2, AL3
### 2.1.3-S5 — [SOLL]
**Anforderung:** Die Teilnahme an Schulungs- und Sensibilisierungsmaßnahmen wird dokumentiert.
- **Organisatorisch:** Teilnahmepflicht und Nachverfolgung nicht abgeschlossener Schulungen regeln.
- **Technisch:** Automatische Teilnahme-/Abschlussdokumentation im LMS mit Reporting.
- **Typische Nachweise:** Teilnahmelisten/Abschlussberichte, Quotenauswertung.
- **Vorlage:** R05; VA-12
- **Ressourcen:** ISB/HR, gering.
- **AL-Filter:** AL2, AL3
### 2.1.3-S6 — [SOLL]
**Anforderung:** Ansprechpartner für Informationssicherheit sind den Beschäftigten bekannt.
- **Organisatorisch:** ISB/Kontaktwege in Onboarding, Intranet und Schulungen kommunizieren.
- **Technisch:** Kontaktseite/Meldekanal im Intranet prominent verlinken.
- **Typische Nachweise:** Intranet-Seite, Onboarding-Unterlagen mit Ansprechpartnern.
- **Vorlage:** R05; VA-12
- **Ressourcen:** ISB, gering.
- **AL-Filter:** AL2, AL3
## Control 2.1.4 — Mobiles Arbeiten
### 2.1.4-M1 — [MUSS]
**Anforderung:** Die Anforderungen an mobiles Arbeiten sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
- **Organisatorisch:** Richtlinie mobiles Arbeiten/Homeoffice mit Regeln zu Umgebung, Umgang mit Informationen, VPN-Pflicht und Meldewegen erstellen und verbindlich machen.
- **Technisch:** Sichere Fernzugriffe (VPN/ZTNA), verschlüsselte Endgeräte und MDM-gestützte Richtliniendurchsetzung (BL-EUC-01 Endgeräteschutz).
- **Typische Nachweise:** Richtlinie mobiles Arbeiten, VPN-/MDM-Konfiguration, Kenntnisnahmen.
- **Vorlage:** R06
- **Ressourcen:** ISB + IT, mittel; VPN/MDM ggf. auszubauen — führt zu Aufgabe.
- **AL-Filter:** AL2, AL3
### 2.1.4-S1 — [SOLL]
**Anforderung:** Die einschlägigen Aspekte des mobilen Arbeitens werden berücksichtigt.
- **Organisatorisch:** Aspekte wie Clean Desk unterwegs, Nutzung öffentlicher Netze, Umgang mit vertraulichen Gesprächen und Papierdokumenten in der Richtlinie konkretisieren.
- **Technisch:** Automatische Bildschirmsperre, Festplattenverschlüsselung und Netzwerkabsicherung technisch erzwingen (BL-EUC-01).
- **Typische Nachweise:** Richtlinienabschnitt mit Aspektliste, technische Konfigurationsnachweise.
- **Vorlage:** R06
- **Ressourcen:** ISB + IT, gering.
- **AL-Filter:** AL2, AL3
### 2.1.4-S2 — [SOLL]
**Anforderung:** Sensibilisierung der Beschäftigten.
- **Organisatorisch:** Spezifisches Awareness-Modul zu Risiken des mobilen Arbeitens einbinden.
- **Technisch:** Modul im LMS bereitstellen und Teilnahme nachhalten.
- **Typische Nachweise:** Schulungsinhalt „Mobiles Arbeiten", Teilnahmenachweise.
- **Vorlage:** R06; VA-12
- **Ressourcen:** ISB, gering.
- **AL-Filter:** AL2, AL3
### 2.1.4-H1 — [HOCH]
**Anforderung:** Schutzmaßnahmen gegen Abhören und Einsehen sind umgesetzt. (C)
- **Organisatorisch:** Vorgaben für vertrauliche Umgebungen (keine Bearbeitung sensibler Daten in öffentlichen Bereichen, diskrete Gesprächsführung) verbindlich regeln.
- **Technisch:** Blickschutzfilter, automatische Sperre bei Inaktivität, Verzicht auf ungesicherte WLANs; verschlüsselte Kommunikation (BL-EUC-02 Sichtschutz/Session-Lock).
- **Typische Nachweise:** Ausgabe/Nachweis Blickschutzfilter, Richtlinienregelung, Konfiguration Bildschirmsperre.
- **Vorlage:** R06
- **Ressourcen:** IT, gering; Beschaffung Blickschutzfilter — führt zu Aufgabe.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 3.1.1 — Sicherheitszonen und Zutrittsschutz
### 3.1.1-M1 — [MUSS]
**Anforderung:** Ein Sicherheitszonenkonzept einschließlich zugehöriger Schutzmaßnahmen auf Basis der Anforderungen an die Handhabung von Informationswerten ist vorhanden.
- **Organisatorisch:** Zonenmodell (z. B. öffentlich, intern, geschützt, hochsicher) mit Schutzanforderungen je Zone definieren und Standorte/Räume zuordnen.
- **Technisch:** Zutrittskontrollsystem, Zonenpläne und bauliche/technische Maßnahmen (Türen, Schließanlage, Einbruchmeldeanlage) je Zone abbilden (BL-PHY-01 Zonenmodell).
- **Typische Nachweise:** Sicherheitszonenkonzept, Zonen-/Raumplan, Maßnahmenzuordnung je Zone.
- **Vorlage:** R07
- **Ressourcen:** ISB + Facility, mittel; bauliche Maßnahmen ggf. investiv — führt zu Aufgabe.
- **AL-Filter:** AL2, AL3
### 3.1.1-M2 — [MUSS]
**Anforderung:** Die definierten Schutzmaßnahmen sind umgesetzt.
- **Organisatorisch:** Umsetzungsstand je Zone/Standort prüfen und Restmaßnahmen nachverfolgen.
- **Technisch:** Zutrittskontrolle, Schließanlage, EMA/Videoüberwachung gemäß Konzept in Betrieb; Wirksamkeit prüfen.
- **Typische Nachweise:** Umsetzungsnachweise (Fotos, Abnahmen), Konfiguration Zutrittskontrolle, Begehungsprotokoll.
- **Vorlage:** R07
- **Ressourcen:** Facility + IT, mittel.
- **AL-Filter:** AL2, AL3
### 3.1.1-M3 — [MUSS]
**Anforderung:** Der Verhaltenskodex für Sicherheitszonen ist allen beteiligten Personen bekannt.
- **Organisatorisch:** Verhaltensregeln je Zone (Zutritt, Begleitung, Foto-/Geräteverbot) dokumentieren und kommunizieren; Aushänge an Zonenübergängen.
- **Technisch:** Kodex im Intranet bereitstellen; Kenntnisnahme über Portal erfassen.
- **Typische Nachweise:** Verhaltenskodex, Aushänge, Kenntnisnahmen.
- **Vorlage:** R07
- **Ressourcen:** ISB + Facility, gering.
- **AL-Filter:** AL2, AL3
### 3.1.1-S1 — [SOLL]
**Anforderung:** Verfahren für die Vergabe und den Entzug von Zutrittsrechten sind etabliert.
- **Organisatorisch:** Antrags-, Genehmigungs- und Entzugsprozess für Zutrittsrechte (inkl. Deprovisionierung bei Austritt) definieren.
- **Technisch:** Zutrittsrechte im Zutrittskontrollsystem rollenbasiert vergeben; Entzug an HR-Austrittsprozess koppeln (BL-PHY-02 Zutrittsberechtigungen).
- **Typische Nachweise:** Verfahrensbeschreibung, Zutrittsrechteanträge, Berechtigungsliste.
- **Vorlage:** R07; VA-17
- **Ressourcen:** Facility + HR, gering–mittel.
- **AL-Filter:** AL2, AL3
### 3.1.1-S2 — [SOLL]
**Anforderung:** Richtlinien für das Besuchermanagement (Registrierung, Begleitung) sind definiert.
- **Organisatorisch:** Besucherrichtlinie mit Anmeldung, Ausweispflicht, Begleitung und Belehrung festlegen.
- **Technisch:** Besuchermanagement-System/Besucherbuch mit Ein-/Ausgangserfassung und Badge-Vergabe.
- **Typische Nachweise:** Besucherrichtlinie, Besucherprotokolle, Besucherausweise.
- **Vorlage:** R07; VA-17
- **Ressourcen:** Empfang/Facility, gering.
- **AL-Filter:** AL2, AL3
### 3.1.1-S3 — [SOLL]
**Anforderung:** Richtlinien für das Mitführen und Nutzen mobiler IT-Geräte und Datenträger sind definiert und umgesetzt.
- **Organisatorisch:** Regeln zu Registrierung, Kennzeichnung und Nutzung mitgeführter Geräte/Datenträger in sensiblen Zonen festlegen.
- **Technisch:** Kennzeichnungs-/Registrierungssystem; ggf. technische Sperren (Portkontrolle) in Hochsicherheitszonen.
- **Typische Nachweise:** Richtlinie, Geräteregister, Kennzeichnungsnachweise.
- **Vorlage:** R07; VA-17
- **Ressourcen:** ISB + Facility, gering.
- **AL-Filter:** AL2, AL3
### 3.1.1-S4 — [SOLL]
**Anforderung:** Netzwerk-/Infrastrukturkomponenten (eigene oder Kundennetze) sind gegen unbefugten Zugriff geschützt.
- **Organisatorisch:** Verantwortlichkeiten und Zutrittsregeln für Technik-/Verteilerräume festlegen.
- **Technisch:** Verschließbare Verteiler/Serverräume, Zutrittsprotokollierung, physische Sicherung von Netzkomponenten (BL-PHY-03 Technikräume).
- **Typische Nachweise:** Zutrittsprotokolle Technikräume, Fotonachweis Absicherung, Schließplan.
- **Vorlage:** R07; VA-17
- **Ressourcen:** Facility + IT, gering–mittel.
- **AL-Filter:** AL2, AL3
### 3.1.1-S5 — [SOLL]
**Anforderung:** Externe Liegenschaften zur Speicherung/Verarbeitung von Informationswerten sind im Zonenkonzept berücksichtigt.
- **Organisatorisch:** Externe Standorte (Lager, Werkstätten, Teststrecken, RZ) erfassen und ins Zonenkonzept einordnen; vertragliche Sicherheitsanforderungen prüfen.
- **Technisch:** Zonen-/Schutzanforderungen auf externe Liegenschaften übertragen und deren Umsetzung nachweisen.
- **Typische Nachweise:** Liste externer Liegenschaften, Zonen-Zuordnung, Nachweise externer Schutzmaßnahmen.
- **Vorlage:** R07; VA-17
- **Ressourcen:** ISB + Facility, gering.
- **AL-Filter:** AL2, AL3
### 3.1.1-H1 — [HOCH]
**Anforderung:** Schutzmaßnahmen gegen einfaches Abhören und Einsehen sind umgesetzt. (C)
- **Organisatorisch:** Sensible Besprechungs-/Arbeitsräume ausweisen und Nutzungsregeln (kein Einsehen von außen, keine unbefugten Aufzeichnungen) festlegen.
- **Technisch:** Sichtschutz (Folien/Jalousien), Schallschutz, ggf. Abschirmung; kontrollierter Zutritt zu sensiblen Räumen (BL-PHY-04 Abhör-/Sichtschutz).
- **Typische Nachweise:** Raumkonzept sensibler Räume, Nachweis Sicht-/Schallschutzmaßnahmen.
- **Vorlage:** R07
- **Ressourcen:** Facility, mittel; bauliche Maßnahmen ggf. investiv — führt zu Aufgabe.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 3.1.4 — Mobile IT-Geräte und Datenträger
### 3.1.4-M1 — [MUSS]
**Anforderung:** Die Anforderungen an mobile IT-Geräte und mobile Datenträger sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
- **Organisatorisch:** Richtlinie zu mobilen Geräten/Datenträgern (zugelassene Geräte, Nutzung, Aufbewahrung, Verlust-Meldung, Rückgabe) festlegen.
- **Technisch:** Zentrale Verwaltung über MDM/UEM mit erzwungenen Sicherheitsprofilen; Kontrolle des Wechseldatenträgereinsatzes (BL-EUC-01 Endgeräteschutz).
- **Typische Nachweise:** Richtlinie mobile Geräte/Datenträger, MDM-Richtlinien, Kenntnisnahmen.
- **Vorlage:** R06
- **Ressourcen:** IT + ISB, mittel; MDM/UEM ggf. zu beschaffen/ausbauen — führt zu Aufgabe.
- **AL-Filter:** AL2, AL3
### 3.1.4-S1 — [SOLL]
**Anforderung:** Registrierung der IT-Geräte.
- **Organisatorisch:** Verbindliche Registrierung mobiler Geräte im Bestand (Zuordnung Nutzer/Gerät) vor Ausgabe.
- **Technisch:** Inventarisierung über MDM/CMDB mit eindeutiger Geräte-ID und Statuspflege.
- **Typische Nachweise:** Geräteinventar/CMDB-Auszug, Übergabeprotokolle.
- **Vorlage:** R06
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 3.1.4-H1 — [HOCH]
**Anforderung:** Generelle Verschlüsselung mobiler Datenträger bzw. der gespeicherten Informationswerte; wo technisch nicht machbar, gleichwertige Maßnahmen. (C, I)
- **Organisatorisch:** Verschlüsselungspflicht für mobile Geräte/Datenträger verbindlich festlegen; Ausnahmen mit gleichwertigen Ersatzmaßnahmen dokumentieren.
- **Technisch:** Full-Disk-Encryption (z. B. BitLocker/FileVault) und Verschlüsselung von Wechseldatenträgern per MDM erzwingen; zentrales Schlüssel-/Recovery-Management (BL-CRY-02 Datenträgerverschlüsselung).
- **Typische Nachweise:** Verschlüsselungsrichtlinie, MDM-Compliance-Report (Encryption-Status), Ausnahmedokumentation.
- **Vorlage:** R06
- **Ressourcen:** IT, gering–mittel; über MDM steuerbar.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 4.1.1 — Identifikationsmittel
### 4.1.1-M1 — [MUSS]
**Anforderung:** Die Anforderungen an den Umgang mit Identifikationsmitteln über den gesamten Lebenszyklus sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
- **Organisatorisch:** Lebenszyklus von Identifikationsmitteln (Ausweise, Token, Schlüssel, Zertifikate) von Ausgabe über Nutzung bis Rückgabe/Sperrung regeln; Verantwortlichkeiten festlegen.
- **Technisch:** Zentrale Verwaltung von Ausweisen/Token/Zertifikaten mit Statusführung; Kopplung an Zutritts-/IAM-System (BL-IAM-06 Identifikationsmittel).
- **Typische Nachweise:** Richtlinie/Verfahren Identifikationsmittel, Ausgabe-/Rückgabeprotokolle, Bestandsführung.
- **Vorlage:** R08
- **Ressourcen:** IT + Facility, mittel.
- **AL-Filter:** AL2, AL3
### 4.1.1-S1 — [SOLL]
**Anforderung:** Identifikationsmittel können nur unter kontrollierten Bedingungen erstellt werden.
- **Organisatorisch:** Erstellung von Ausweisen/Token an autorisierte Stellen und dokumentierte Freigaben binden (Vier-Augen-Prinzip bei sensiblen Mitteln).
- **Technisch:** Zugriff auf Ausweisdrucker/Token-Personalisierung und Zertifikats-CA beschränken und protokollieren (BL-IAM-06).
- **Typische Nachweise:** Berechtigungsnachweis Erstellungssysteme, Erstellungsprotokolle, Freigaben.
- **Vorlage:** R08; VA-03
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.1-H1 — [HOCH]
**Anforderung:** Eine Strategie zur Sperrung oder Ungültigmachung von Identifikationsmitteln im Verlustfall ist vorbereitet und soweit möglich umgesetzt. (C, I, A)
- **Organisatorisch:** Verlust-/Sperrprozess mit definierten Meldewegen und Reaktionszeiten festlegen; Verantwortliche und Erreichbarkeit (auch außerhalb Geschäftszeiten) benennen.
- **Technisch:** Sofortige Sperrung von Ausweisen/Token im Zutritts-/IAM-System, Zertifikatssperrung (CRL/OCSP); Remote-Wipe für Geräte-gebundene Mittel (BL-IAM-06).
- **Typische Nachweise:** Sperrprozess-Beschreibung, dokumentierte Sperrvorgänge, CRL-/Sperrnachweise.
- **Vorlage:** R08
- **Ressourcen:** IT, gering–mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 4.1.2 — Benutzerauthentifizierung
### 4.1.2-M1 — [MUSS]
**Anforderung:** Die Verfahren zur Benutzerauthentifizierung sind auf Basis einer Risikobewertung ausgewählt; mögliche Angriffsszenarien wurden berücksichtigt.
- **Organisatorisch:** Authentifizierungsverfahren je System risikobasiert festlegen (Internet-Exponiertheit, Schutzbedarf); Auswahl dokumentieren.
- **Technisch:** Risikoabhängige Zuordnung von Verfahren (Passwort, MFA, zertifikatsbasiert) in der IAM-Architektur; besonders für extern erreichbare Dienste MFA vorsehen (BL-IAM-02 MFA).
- **Typische Nachweise:** Risikobewertung Authentifizierung, Zuordnung Verfahren je System.
- **Vorlage:** R08; VA-09
- **Ressourcen:** ISB + IT, mittel.
- **AL-Filter:** AL2, AL3
### 4.1.2-M2 — [MUSS]
**Anforderung:** Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt.
- **Organisatorisch:** Mindeststandards für Authentifizierung (starke Passwörter, MFA für kritische/exponierte Zugänge) verbindlich vorgeben.
- **Technisch:** Zentrale Authentifizierung (IdP/SSO) mit MFA; Passwortrichtlinie technisch erzwingen (BL-IAM-01 Passwort, BL-IAM-02 MFA).
- **Typische Nachweise:** IdP-/MFA-Konfiguration, Passwortrichtlinien-Konfiguration, Systemübersicht mit Verfahren.
- **Vorlage:** R08
- **Ressourcen:** IT, mittel; MFA-Ausbau ggf. — führt zu Aufgabe.
- **AL-Filter:** AL2, AL3
### 4.1.2-S1 — [SOLL]
**Anforderung:** Die Authentifizierungsverfahren sind auf Basis der geschäftlichen und sicherheitsrelevanten Anforderungen definiert und umgesetzt.
- **Organisatorisch:** Anforderungen aus Fachbereichen und Sicherheit je Anwendung abstimmen und Zielverfahren festlegen.
- **Technisch:** Verfahren im IdP/Anwendungsstack konfigurieren und rollout-seitig durchsetzen.
- **Typische Nachweise:** Konzept Authentifizierungsverfahren, Konfigurationsnachweise.
- **Vorlage:** R08
- **Ressourcen:** IT, gering–mittel.
- **AL-Filter:** AL2, AL3
### 4.1.2-S2 — [SOLL]
**Anforderung:** Benutzer werden mindestens durch starke Passwörter nach bewährten und anerkannten Praktiken authentifiziert.
- **Organisatorisch:** Passwortrichtlinie (Länge, Komplexität/Passphrasen, Sperrung kompromittierter Passwörter) gemäß anerkannter Praxis festlegen.
- **Technisch:** Richtlinie zentral erzwingen (Directory/IdP), Sperrlisten für kompromittierte Passwörter, keine erzwungenen periodischen Wechsel ohne Anlass (BL-IAM-01 Passwort).
- **Typische Nachweise:** Passwortrichtlinie, Directory-/IdP-Konfiguration.
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.2-S3 — [SOLL]
**Anforderung:** Für privilegierte Benutzerkonten werden höherwertige Verfahren genutzt (z. B. PAM, Zwei-Faktor-Authentifizierung).
- **Organisatorisch:** MFA-Pflicht und PAM-Nutzung für administrative/privilegierte Konten festlegen.
- **Technisch:** Privileged-Access-Management mit Session-Kontrolle und obligatorischer MFA für Admin-Zugänge (BL-IAM-05 Privileged Access).
- **Typische Nachweise:** PAM-Konfiguration, MFA-Nachweis Admin-Konten, Liste privilegierter Konten.
- **Vorlage:** R08
- **Ressourcen:** IT, mittel; PAM ggf. zu beschaffen — führt zu Aufgabe.
- **AL-Filter:** AL2, AL3
### 4.1.2-H1 — [HOCH]
**Anforderung:** Authentifizierung und Zugangskontrolle sind durch ergänzende Maßnahmen verstärkt (z. B. Zugriffsüberwachung, starke Authentifizierung, automatische Abmeldung, Sperre bei Inaktivität, Brute-Force-Prävention). (C, I, A)
- **Organisatorisch:** Risikobasiert ergänzende Schutzmaßnahmen je System festlegen und deren Wirksamkeit prüfen.
- **Technisch:** Account-Lockout/Brute-Force-Schutz, Session-Timeout und automatische Abmeldung, kontinuierliches Zugriffs-/Anomaliemonitoring (SIEM) (BL-IAM-02, BL-IAM-05).
- **Typische Nachweise:** Konfiguration Lockout/Session-Timeout, Monitoring-/SIEM-Nachweise.
- **Vorlage:** R08
- **Ressourcen:** IT, mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 4.1.2-V1 — [SEHR HOCH]
**Anforderung:** Vor dem Zugriff auf Daten mit sehr hohem Schutzbedarf werden Benutzer mittels starker Authentifizierung (z. B. Zwei-Faktor) nach dem Stand der Technik authentifiziert. (C, I)
- **Organisatorisch:** Für Zugriffe auf sehr hoch schutzbedürftige Daten verbindliche Starke-Authentifizierung-Pflicht festlegen.
- **Technisch:** Phishing-resistente MFA (z. B. FIDO2/Zertifikate) für den Zugang zu sehr hoch klassifizierten Daten erzwingen (BL-IAM-02 MFA).
- **Typische Nachweise:** MFA-Enforcement-Konfiguration für Zielsysteme, Zugriffsprotokolle.
- **Vorlage:** R08
- **Ressourcen:** IT, mittel.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 4.1.3 — Benutzerkonten
### 4.1.3-M1 — [MUSS]
**Anforderung:** Das Erstellen, Ändern und Löschen von Benutzerkonten wird durchgeführt.
- **Organisatorisch:** Joiner-Mover-Leaver-Prozess mit Verantwortlichkeiten und Auslösern (HR-Events) definieren.
- **Technisch:** Kontenlebenszyklus über IAM/Provisioning möglichst automatisiert an HR-System koppeln (BL-IAM-03 Kontenlebenszyklus).
- **Typische Nachweise:** Prozessbeschreibung JML, Provisioning-Logs, Beispiel-Tickets.
- **Vorlage:** R08; VA-03
- **Ressourcen:** IT + HR, mittel.
- **AL-Filter:** AL2, AL3
### 4.1.3-M2 — [MUSS]
**Anforderung:** Eindeutige und personalisierte Benutzerkonten werden verwendet.
- **Organisatorisch:** Grundsatz personalisierter Konten festlegen; Ausnahmen (Sammelkonten) nur geregelt zulassen.
- **Technisch:** Eindeutige Namenskonvention und ID-Vergabe im Directory; keine geteilten personenbezogenen Logins.
- **Typische Nachweise:** Namenskonvention, Kontenauswertung Directory.
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-M3 — [MUSS]
**Anforderung:** Die Nutzung von Sammelkonten ist geregelt (z. B. beschränkt auf Fälle, in denen Nachvollziehbarkeit verzichtbar ist).
- **Organisatorisch:** Zulässige Anwendungsfälle, Genehmigung und Verantwortliche für Sammelkonten dokumentieren.
- **Technisch:** Sammelkonten inventarisieren, Zugriff einschränken und, wo möglich, ergänzend protokollieren.
- **Typische Nachweise:** Regelung Sammelkonten, Liste genehmigter Sammelkonten.
- **Vorlage:** R08
- **Ressourcen:** IT + ISB, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-M4 — [MUSS]
**Anforderung:** Benutzerkonten werden unmittelbar nach dem Ausscheiden des Nutzers deaktiviert (z. B. bei Vertragsende).
- **Organisatorisch:** Austrittsprozess mit sofortiger Kontensperrung und definierter Frist verbindlich festlegen.
- **Technisch:** Automatische Deaktivierung durch HR-getriggertes Deprovisioning im IAM (BL-IAM-03 Kontenlebenszyklus).
- **Typische Nachweise:** Deaktivierungsnachweise, Austritts-/Deprovisioning-Logs, Fristdefinition.
- **Vorlage:** R08
- **Ressourcen:** IT + HR, gering–mittel.
- **AL-Filter:** AL2, AL3
### 4.1.3-M5 — [MUSS]
**Anforderung:** Benutzerkonten werden regelmäßig überprüft.
- **Organisatorisch:** Turnus für Kontenreviews (Rezertifizierung) mit Verantwortlichen festlegen.
- **Technisch:** Reports über aktive/inaktive/verwaiste Konten aus IAM/Directory; ggf. Recertification-Workflow (BL-IAM-03).
- **Typische Nachweise:** Review-Protokolle, Reports verwaister Konten, Rezertifizierungsnachweise.
- **Vorlage:** R08
- **Ressourcen:** IT + Fachbereiche, gering–mittel; wiederkehrend.
- **AL-Filter:** AL2, AL3
### 4.1.3-M6 — [MUSS]
**Anforderung:** Die Anmeldeinformationen werden dem Nutzer auf sichere Weise bereitgestellt.
- **Organisatorisch:** Sicheren Übergabeprozess für Erstzugangsdaten definieren (getrennte Kanäle, erzwungener Wechsel bei Erstanmeldung).
- **Technisch:** Initialpasswörter über sichere Kanäle, Einmalpasswörter/Aktivierungslinks, erzwungener Passwortwechsel bei Erstanmeldung (BL-IAM-01 Passwort).
- **Typische Nachweise:** Prozessbeschreibung Erstzugang, Konfiguration erzwungener Wechsel.
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-M7 — [MUSS]
**Anforderung:** Eine Richtlinie zum Umgang mit Anmeldeinformationen ist definiert und umgesetzt; dabei werden die einschlägigen Aspekte berücksichtigt.
- **Organisatorisch:** Richtlinie zum Umgang mit Credentials (Geheimhaltung, keine Weitergabe, Umgang bei Verdacht auf Kompromittierung) erstellen und kommunizieren.
- **Technisch:** Bereitstellung eines Passwort-Managers, Vorgaben zu Speicherung/Nutzung technisch unterstützen (BL-IAM-01).
- **Typische Nachweise:** Credential-Richtlinie, Kenntnisnahmen, Bereitstellung Passwort-Manager.
- **Vorlage:** R08
- **Ressourcen:** ISB + IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-S1 — [SOLL]
**Anforderung:** Ein Basiskonto mit minimalen Zugriffsrechten und Funktionalitäten existiert und wird genutzt.
- **Organisatorisch:** Standard-/Basisprofil mit Minimalrechten als Ausgangsbasis für neue Konten festlegen.
- **Technisch:** Standardrolle mit minimalen Rechten im IAM als Default zuweisen (Least Privilege, BL-IAM-04 Rollenmodell).
- **Typische Nachweise:** Definition Basiskonto/-rolle, Rollenzuordnung im IAM.
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-S2 — [SOLL]
**Anforderung:** Vom Hersteller vorkonfigurierte Standardkonten und -passwörter sind deaktiviert (z. B. Sperren oder Passwortänderung).
- **Organisatorisch:** Hardening-Vorgabe zum Umgang mit Default-Konten bei Inbetriebnahme festlegen.
- **Technisch:** Default-Accounts deaktivieren/umbenennen und Default-Passwörter ändern; über Hardening-Baseline prüfen (BL-OPS-01 Hardening).
- **Typische Nachweise:** Hardening-Checkliste, Nachweis deaktivierter Default-Konten.
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-S3 — [SOLL]
**Anforderung:** Benutzerkonten werden durch die verantwortliche Stelle erstellt oder autorisiert.
- **Organisatorisch:** Zuständige Stelle für Kontenerstellung/-autorisierung benennen.
- **Technisch:** Kontenerstellung an autorisierte Rollen im IAM binden und protokollieren.
- **Typische Nachweise:** Rollen-/Verantwortlichkeitsdefinition, Erstellungsprotokolle.
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-S4 — [SOLL]
**Anforderung:** Das Erstellen von Benutzerkonten unterliegt einem Genehmigungsprozess (Vier-Augen-Prinzip).
- **Organisatorisch:** Genehmigungspflicht mit Vier-Augen-Prinzip für Kontenerstellung festlegen.
- **Technisch:** Approval-Workflow im IAM/ITSM mit dokumentierter Freigabe.
- **Typische Nachweise:** Workflow-Konfiguration, Genehmigungsnachweise/Tickets.
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-S5 — [SOLL]
**Anforderung:** Benutzerkonten von Dienstleistern werden nach Abschluss ihrer Aufgabe deaktiviert.
- **Organisatorisch:** Befristung und Verantwortliche für Dienstleisterkonten festlegen; Ende an Auftrags-/Vertragsende koppeln.
- **Technisch:** Ablaufdatum (Account-Expiry) für externe Konten im IAM setzen und überwachen (BL-IAM-03).
- **Typische Nachweise:** Liste Dienstleisterkonten mit Ablaufdatum, Deaktivierungsnachweise.
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-S6 — [SOLL]
**Anforderung:** Fristen für das Deaktivieren und Löschen von Benutzerkonten sind definiert.
- **Organisatorisch:** Fristen für Deaktivierung und endgültige Löschung (unter Beachtung von Aufbewahrungspflichten) definieren.
- **Technisch:** Fristen im IAM/Prozess automatisiert überwachen und umsetzen.
- **Typische Nachweise:** Fristenregelung, Nachweis fristgerechter Löschungen.
- **Vorlage:** R08
- **Ressourcen:** IT + ISB, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-S7 — [SOLL]
**Anforderung:** Die Verwendung von Standardpasswörtern wird technisch verhindert.
- **Organisatorisch:** Vorgabe, dass Default-/triviale Passwörter unzulässig sind.
- **Technisch:** Erzwungener Wechsel bei Erstanmeldung, Sperrlisten trivialer Passwörter im IdP (BL-IAM-01).
- **Typische Nachweise:** IdP-Konfiguration (Sperrliste, Erstwechsel).
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
### 4.1.3-S8 — [SOLL]
**Anforderung:** Bei starker Authentifizierung ist die Nutzung des Mediums (z. B. Besitzfaktor) sicher.
- **Organisatorisch:** Regeln zur Ausgabe, Nutzung und Rückgabe von Token/Besitzfaktoren festlegen.
- **Technisch:** Sichere Token (Hardware-/FIDO2), PIN-Schutz und sichere Registrierung/Sperrung (BL-IAM-02 MFA).
- **Typische Nachweise:** Token-Ausgaberegelung, Konfiguration MFA-Registrierung/Sperrung.
- **Vorlage:** R08
- **Ressourcen:** IT, gering–mittel.
- **AL-Filter:** AL2, AL3
### 4.1.3-S9 — [SOLL]
**Anforderung:** Benutzerkonten werden regelmäßig überprüft; dies umfasst auch Konten in IT-Systemen von Kunden.
- **Organisatorisch:** Kontenreviews auf Kundensysteme ausdehnen; Verantwortliche und Turnus je Kundenkontext festlegen.
- **Technisch:** Kontenlisten aus Kundensystemen periodisch abgleichen und rezertifizieren.
- **Typische Nachweise:** Review-Protokolle inkl. Kundensysteme, Rezertifizierungsnachweise.
- **Vorlage:** R08
- **Ressourcen:** IT + Fachbereiche, mittel; wiederkehrend.
- **AL-Filter:** AL2, AL3
### 4.1.3-S10 — [SOLL]
**Anforderung:** Interaktive Anmeldung für Dienstkonten (technische Konten) wird technisch verhindert.
- **Organisatorisch:** Grundsatz „keine interaktive Anmeldung für Servicekonten" festlegen und Servicekonten inventarisieren.
- **Technisch:** Interaktive Logins per Richtlinie (z. B. Deny-Logon-Policy) unterbinden; Servicekonten mit minimalen Rechten und Managed/gMSA nutzen (BL-IAM-04).
- **Typische Nachweise:** Servicekonten-Inventar, Richtlinienkonfiguration (Deny interactive logon).
- **Vorlage:** R08
- **Ressourcen:** IT, gering.
- **AL-Filter:** AL2, AL3
## Control 4.2.1 — Verwaltung von Zugriffsrechten
### 4.2.1-M1 — [MUSS]
**Anforderung:** Die Anforderungen an die Verwaltung von Zugriffsrechten (Autorisierung) sind bestimmt und erfüllt; dabei werden die einschlägigen Aspekte berücksichtigt.
- **Organisatorisch:** Berechtigungskonzept mit Antrags-, Genehmigungs-, Änderungs- und Entzugsprozess sowie Least-Privilege-Grundsatz definieren.
- **Technisch:** Zentrale Rechteverwaltung über IAM; rollenbasierte Vergabe und Nachverfolgbarkeit (BL-IAM-04 Rollenmodell).
- **Typische Nachweise:** Berechtigungskonzept, Antrags-/Genehmigungsnachweise, Rechteübersicht.
- **Vorlage:** R08; VA-03
- **Ressourcen:** ISB + IT, mittel.
- **AL-Filter:** AL2, AL3
### 4.2.1-M2 — [MUSS]
**Anforderung:** Die für normale, privilegierte und technische Konten vergebenen Zugriffsrechte werden regelmäßig überprüft, auch in IT-Systemen von Kunden.
- **Organisatorisch:** Rezertifizierung der Zugriffsrechte in festem Turnus mit Fachverantwortlichen; Kundensysteme einschließen.
- **Technisch:** Access-Recertification-Workflow im IAM mit Reports je Kontotyp (BL-IAM-04, BL-IAM-05 Privileged Access).
- **Typische Nachweise:** Rezertifizierungsprotokolle, Rechte-Reports (inkl. privilegiert/technisch/Kunde).
- **Vorlage:** R08; VA-03
- **Ressourcen:** IT + Fachbereiche, mittel; wiederkehrend.
- **AL-Filter:** AL2, AL3
### 4.2.1-S1 — [SOLL]
**Anforderung:** Strategien zur Autorisierung von Zugriffen auf Informationen sind vorbereitet.
- **Organisatorisch:** Autorisierungsstrategie (z. B. RBAC, Need-to-know, Datenklassifizierung als Grundlage) dokumentieren.
- **Technisch:** Strategie in IAM-Rollen-/Policy-Modell überführen.
- **Typische Nachweise:** Autorisierungsstrategie/-konzept.
- **Vorlage:** R08; VA-03
- **Ressourcen:** ISB + IT, gering.
- **AL-Filter:** AL2, AL3
### 4.2.1-S2 — [SOLL]
**Anforderung:** Autorisierungsrollen werden verwendet.
- **Organisatorisch:** Rollenmodell mit definierten Berechtigungsbündeln je Funktion etablieren und pflegen.
- **Technisch:** RBAC im IAM abbilden; Rollen zentral verwalten und zuweisen (BL-IAM-04).
- **Typische Nachweise:** Rollenkatalog, Rollen-Rechte-Matrix.
- **Vorlage:** R08
- **Ressourcen:** IT, mittel.
- **AL-Filter:** AL2, AL3
### 4.2.1-S3 — [SOLL]
**Anforderung:** Rechte werden nach dem Need-to-use-Prinzip und gemäß Rolle und/oder Verantwortungsbereich vergeben.
- **Organisatorisch:** Vergabe strikt am tatsächlichen Bedarf und an der Rolle ausrichten; Sammelberechtigungen vermeiden.
- **Technisch:** Least-Privilege-Rollen im IAM; regelmäßige Bereinigung überschüssiger Rechte.
- **Typische Nachweise:** Rechtevergabe-Nachweise, Bereinigungsprotokolle.
- **Vorlage:** R08
- **Ressourcen:** IT, gering–mittel.
- **AL-Filter:** AL2, AL3
### 4.2.1-S4 — [SOLL]
**Anforderung:** Normale Benutzerkonten erhalten keine privilegierten Zugriffsrechte.
- **Organisatorisch:** Trennung von Standard- und Administrationskonten verbindlich vorschreiben.
- **Technisch:** Getrennte Admin-Konten, Entzug lokaler Adminrechte auf Endgeräten, Just-in-Time-Admin über PAM (BL-IAM-05).
- **Typische Nachweise:** Nachweis getrennter Admin-Konten, Auswertung lokaler Adminrechte.
- **Vorlage:** R08
- **Ressourcen:** IT, mittel.
- **AL-Filter:** AL2, AL3
### 4.2.1-S5 — [SOLL]
**Anforderung:** Die Zugriffsrechte des Nutzers werden nach Änderung seiner Verantwortlichkeiten aktualisiert.
- **Organisatorisch:** Mover-Prozess mit Neubewertung und Entzug nicht mehr benötigter Rechte bei Rollenwechsel definieren.
- **Technisch:** HR-getriggerte Rechteanpassung im IAM; Entzug alter Rollen (BL-IAM-03, BL-IAM-04).
- **Typische Nachweise:** Mover-Prozessbeschreibung, Änderungsnachweise Rechte.
- **Vorlage:** R08
- **Ressourcen:** IT + HR, gering–mittel.
- **AL-Filter:** AL2, AL3
### 4.2.1-H1 — [HOCH]
**Anforderung:** Die Zugriffsrechte werden durch den verantwortlichen internen Information Officer genehmigt. (C, I, A)
- **Organisatorisch:** Genehmigung sensibler Zugriffsrechte durch den zuständigen Informationsverantwortlichen (Dateneigentümer) verbindlich festlegen.
- **Technisch:** Approval-Workflow mit Owner-Freigabe im IAM/ITSM; Genehmigungen revisionssicher protokollieren.
- **Typische Nachweise:** Freigabe-Workflow-Konfiguration, dokumentierte Owner-Genehmigungen.
- **Vorlage:** R08
- **Ressourcen:** IT + Fachbereiche, gering–mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 4.2.1-V1 — [SEHR HOCH]
**Anforderung:** Informationen werden auf Inhaltsebene (z. B. Dateiebene) verschlüsselt gespeichert, um unbefugten Zugriff (auch privilegierter Nutzer) zu verhindern; wo nicht machbar, gleichwertige Maßnahmen. (C)
- **Organisatorisch:** Für sehr hoch schutzbedürftige Daten Inhalts-/Dateiverschlüsselung mit strikter Schlüsseltrennung von Administratoren vorschreiben; Ausnahmen mit Ersatzmaßnahmen dokumentieren.
- **Technisch:** Datei-/Feldverschlüsselung mit nutzer-/gruppenbezogenem Schlüsselmanagement, sodass privilegierte Nutzer ohne Schlüssel keinen Klartextzugriff haben (BL-CRY-01 Inhaltsverschlüsselung).
- **Typische Nachweise:** Verschlüsselungskonzept, Nachweis Datei-/Inhaltsverschlüsselung, Schlüsselmanagement-Dokumentation.
- **Vorlage:** R08
- **Ressourcen:** IT + ISB, hoch; Verschlüsselungslösung/Key-Management ggf. zu beschaffen — führt zu Aufgabe.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
### 4.2.1-V2 — [SEHR HOCH]
**Anforderung:** Bestehende Zugriffsrechte werden in kürzeren Abständen (z. B. quartalsweise) überprüft. (C)
- **Organisatorisch:** Verkürzten Rezertifizierungsturnus (z. B. quartalsweise) für sehr hoch schutzbedürftige Bereiche festlegen.
- **Technisch:** Häufigere, automatisierte Recertification-Kampagnen im IAM mit Reporting (BL-IAM-04).
- **Typische Nachweise:** Quartalsweise Rezertifizierungsprotokolle, IAM-Kampagnenauswertung.
- **Vorlage:** R08
- **Ressourcen:** IT + Fachbereiche, mittel; wiederkehrend.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
---
# Kapitel 5 — Kryptographie & Betriebssicherheit
# C6 – Umsetzungshinweise Kapitel 5 (Betriebssicherheit, Kommunikation, Systementwicklung)
## Control 5.1.1 — Einsatz von Kryptografie
### 5.1.1-M1 — [MUSS]
**Anforderung:** Alle eingesetzten kryptografischen Verfahren bieten die im Anwendungsfeld erforderliche Sicherheit nach anerkanntem Industriestandard.
- **Organisatorisch:** Bestand der genutzten Krypto-Verfahren (Verschlüsselung, Signatur, Hash, Protokolle) je Anwendungsfall erheben und gegen aktuelle Empfehlungen (z. B. BSI TR-02102, NIST) abgleichen; veraltete Verfahren (z. B. TLS < 1.2, SHA-1, MD5) außer Betrieb nehmen.
- **Technisch:** Freigegebene Algorithmen und Mindestschlüssellängen zentral als Baseline vorgeben und in Systemkonfigurationen erzwingen (z. B. TLS-Policies, Cipher-Suites, Disk-Encryption). Referenz: BL-CRY-01 (zugelassene Algorithmen/Schlüssellängen), BL-CRY-02 (TLS-Mindeststandard).
- **Typische Nachweise:** Krypto-Katalog/Algorithmenliste mit Freigabestatus, Konfigurationsauszüge (z. B. TLS-Scan), Nachweis Ablösung veralteter Verfahren.
- **Vorlage:** R09; VA-07; BL-CRY-01; BL-CRY-02
- **Ressourcen:** ISB/IT-Betrieb; ggf. TLS-/Config-Scanner (Beschaffung möglich); gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.1.1-S1 — [SOLL]
**Anforderung:** Ein Konzept für den Einsatz von Kryptografie ist definiert und umgesetzt.
- **Organisatorisch:** Kryptokonzept erstellen (Einsatzzwecke, zugelassene Verfahren, Schlüssellängen, Gültigkeitsdauern, Verantwortlichkeiten, Ausnahmeverfahren) und durch die Leitung freigeben lassen.
- **Technisch:** Konzeptvorgaben in Gerätehärtung, PKI-/Zertifikatsmanagement und Verschlüsselungsprofilen technisch verankern. Referenz: BL-CRY-01, BL-CRY-02.
- **Typische Nachweise:** Freigegebenes Kryptokonzept, Zuordnung Verfahren↔Anwendungsfall, Review-Vermerk.
- **Vorlage:** R09; VA-07; BL-CRY-01
- **Ressourcen:** ISB + IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.1.1-H1 — [HOCH]
**Anforderung:** Anforderungen an die Schlüsselhoheit (insbesondere bei externer Verarbeitung) sind bestimmt und erfüllt. (C, I)
- **Organisatorisch:** Für Daten mit hohem Schutzbedarf festlegen, dass Schlüssel unter eigener Kontrolle verbleiben (kein Zugriff des Dienstleisters); Schlüsselverwaltungsverantwortung und Rückgabe-/Löschprozesse vertraglich regeln.
- **Technisch:** Bring-Your-Own-Key/Hold-Your-Own-Key bzw. dedizierte Key-Management-Lösung oder HSM einsetzen; Schlüsseltrennung von Cloud-Anbieter-Schlüsseln. Referenz: BL-CRY-03 (Schlüsselhoheit/Key-Management).
- **Typische Nachweise:** KMS-/HSM-Konfiguration, Vertragsklausel Schlüsselhoheit, Nachweis getrennter Schlüsselverwaltung.
- **Vorlage:** R09; BL-CRY-03
- **Ressourcen:** KMS/HSM oder BYOK-Funktion (Beschaffung/Lizenz möglich); mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 5.1.2 — Sicherheit bei der Informationsübertragung / Netzdienste
### 5.1.2-M1 — [MUSS]
**Anforderung:** Die zur Informationsübertragung genutzten Netzdienste sind identifiziert und dokumentiert.
- **Organisatorisch:** Übersicht der Übertragungswege/Netzdienste (E-Mail, VPN, Fileshare, EDI, Webportale, Fernzugriff) erstellen und Verantwortliche zuweisen.
- **Technisch:** Netzdienste-Inventar mit Protokoll, Endpunkten und Schutzbedarf führen; regelmäßig aus Netz-/Firewall-Dokumentation aktualisieren. Referenz: BL-NET-01 (Netzdienste-/Übertragungsinventar).
- **Typische Nachweise:** Netzdienste-Verzeichnis, Datenfluss-/Übertragungsübersicht.
- **Vorlage:** R09; VA-07; BL-NET-01
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.1.2-M2 — [MUSS]
**Anforderung:** Richtlinien und Verfahren entsprechend den Klassifizierungsanforderungen für die Nutzung von Netzdiensten sind definiert und umgesetzt.
- **Organisatorisch:** Nutzungsvorgaben je Klassifizierungsstufe festlegen (welcher Dienst/Verschlüsselung für welche Informationsklasse zulässig ist) und kommunizieren.
- **Technisch:** Vorgaben durch Mail-Gateway-Regeln, erzwungene Transportverschlüsselung und Freigabelisten technisch durchsetzen. Referenz: BL-NET-01, BL-CRY-02.
- **Typische Nachweise:** Richtlinie Informationsübertragung, Gateway-/Mailflow-Regeln, Klassifizierungs-Mapping.
- **Vorlage:** R09; VA-07; BL-CRY-02
- **Ressourcen:** ISB + IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.1.2-M3 — [MUSS]
**Anforderung:** Maßnahmen zum Schutz übertragener Inhalte gegen unbefugten Zugriff sind umgesetzt.
- **Organisatorisch:** Vorgeben, dass schützenswerte Inhalte nur verschlüsselt übertragen werden; Ausnahmen dokumentieren.
- **Technisch:** Transport-/Inhaltsverschlüsselung (TLS, S/MIME, PGP, verschlüsselte Container/Portale) einsetzen; unverschlüsselte Legacy-Protokolle sperren. Referenz: BL-CRY-02, BL-NET-03 (Fernzugriff/VPN).
- **Typische Nachweise:** TLS-/Verschlüsselungsnachweis, verschlüsselter Austauschkanal, Konfigurationsauszug.
- **Vorlage:** R09; BL-CRY-02
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.1.2-S1 — [SOLL]
**Anforderung:** Maßnahmen zur Sicherstellung korrekter Adressierung und korrekter Informationsübertragung sind umgesetzt.
- **Organisatorisch:** Prozesse gegen Fehlversand definieren (4-Augen bei sensiblen Verteilern, Pflege von Verteilerlisten, Sensibilisierung).
- **Technisch:** Maßnahmen wie Autovervollständigungs-Warnungen, Anti-Misdelivery-/DLP-Regeln, Empfängerbestätigung aktivieren. Referenz: BL-NET-01.
- **Typische Nachweise:** DLP-/Mailregeln, Schulungsnachweis, Verteilerpflege-Prozess.
- **Vorlage:** R09; VA-07
- **Ressourcen:** IT-Betrieb; ggf. DLP-Funktion (Beschaffung möglich); gering.
- **AL-Filter:** AL2 + AL3
### 5.1.2-S2 — [SOLL]
**Anforderung:** Elektronischer Datenaustausch erfolgt mittels Inhalts- oder Transportverschlüsselung entsprechend der Klassifizierung.
- **Organisatorisch:** Je Klassifizierungsstufe festlegen, ob Transport- oder Inhaltsverschlüsselung erforderlich ist.
- **Technisch:** TLS-erzwungene Kanäle für interne/Standardübertragung, Inhaltsverschlüsselung (S/MIME, verschlüsselte Archive) für höhere Stufen. Referenz: BL-CRY-01, BL-CRY-02.
- **Typische Nachweise:** Verschlüsselungsmatrix je Klasse, Konfigurationsnachweis.
- **Vorlage:** R09; BL-CRY-02
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.1.2-S3 — [SOLL]
**Anforderung:** Fernzugriffsverbindungen zum Netzwerk der Organisation verfügen über angemessene Sicherheitsmerkmale.
- **Organisatorisch:** Fernzugriffsrichtlinie mit Genehmigung, Mehr-Faktor-Pflicht und Nutzungsbedingungen definieren.
- **Technisch:** VPN nach Stand der Technik mit MFA, starker Verschlüsselung, Endpoint-Prüfung und Sitzungsbegrenzung. Referenz: BL-NET-03 (Fernzugriff/VPN), BL-IAM-02 (MFA).
- **Typische Nachweise:** VPN-Konfiguration, MFA-Nachweis, Fernzugriffsrichtlinie.
- **Vorlage:** R09; BL-NET-03; BL-IAM-02
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.1.2-H1 — [HOCH]
**Anforderung:** Informationen werden verschlüsselt übertragen (mindestens Transportverschlüsselung) oder gleichwertig geschützt. (C)
- **Organisatorisch:** Verbindliche Verschlüsselungspflicht für Informationen mit hohem Schutzbedarf festschreiben; unverschlüsselte Ausnahmen nur mit dokumentierter Ersatzmaßnahme.
- **Technisch:** Transportverschlüsselung durchgängig erzwingen (TLS-Enforcement, verschlüsselte Tunnel); Fallback auf Klartext technisch verhindern. Referenz: BL-CRY-02.
- **Typische Nachweise:** TLS-Enforcement-Policy, Scan-Ergebnis ohne Klartextdienste.
- **Vorlage:** R09; BL-CRY-02
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.1.2-V1 — [SEHR HOCH]
**Anforderung:** Informationen werden inhaltsverschlüsselt übertragen. (C)
- **Organisatorisch:** Für sehr hohen Schutzbedarf Ende-zu-Ende-/Inhaltsverschlüsselung verpflichtend vorschreiben, unabhängig vom Transportweg.
- **Technisch:** Inhaltsverschlüsselung (S/MIME, PGP, verschlüsselte Container mit eigener Schlüsselhoheit) einsetzen; Schlüssel getrennt vom Transportkanal verwalten. Referenz: BL-CRY-01, BL-CRY-03.
- **Typische Nachweise:** Nachweis Ende-zu-Ende-Verschlüsselung, Schlüsselmanagement-Dokumentation.
- **Vorlage:** R09; BL-CRY-03
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 5.2.1 — Änderungsmanagement (Change Management)
### 5.2.1-M1 — [MUSS]
**Anforderung:** Informationssicherheitsanforderungen für Änderungen an Organisation, Geschäftsprozessen und IT-Systemen sind bestimmt und erfüllt.
- **Organisatorisch:** Change-Management-Prozess etablieren, der Sicherheitsbewertung, Freigabe und Dokumentation jeder relevanten Änderung vorsieht.
- **Technisch:** Änderungen über Ticket-/Change-System mit Sicherheitsprüfung und Genehmigungs-Workflow abwickeln. Referenz: BL-OPS-01 (Change-Management).
- **Typische Nachweise:** Change-Records mit Sicherheitsbewertung, Change-Richtlinie, Freigaben.
- **Vorlage:** R10; VA-04; BL-OPS-01
- **Ressourcen:** IT-Betrieb; ggf. Ticket-/Change-Tool (Beschaffung möglich); gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.1-S1 — [SOLL]
**Anforderung:** Ein formales Genehmigungsverfahren ist etabliert.
- **Organisatorisch:** Rollen (Antragsteller, Bewerter, Genehmiger) und Freigabekriterien definieren; ggf. Change Advisory Board.
- **Technisch:** Genehmigungs-Workflow im Change-Tool mit Pflichtfeldern und Freigabestufen abbilden. Referenz: BL-OPS-01.
- **Typische Nachweise:** Genehmigte Changes, Rollen-/Gremienbeschreibung.
- **Vorlage:** R10; VA-04; BL-OPS-01
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.1-S2 — [SOLL]
**Anforderung:** Die möglichen Auswirkungen von Änderungen auf die Informationssicherheit werden bewertet.
- **Organisatorisch:** Impact-/Risikoanalyse als Pflichtschritt im Change vorsehen (betroffene Assets, Schutzziele).
- **Technisch:** Bewertungsfelder/Checkliste im Change-Record, Verknüpfung mit Asset- und Risikoregister. Referenz: BL-OPS-01.
- **Typische Nachweise:** Impact-Analysen in Change-Records, Bewertungscheckliste.
- **Vorlage:** R10; VA-04
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.1-S3 — [SOLL]
**Anforderung:** Änderungen mit Auswirkung auf die Informationssicherheit werden geplant und getestet.
- **Organisatorisch:** Planungs- und Testschritte vor Produktivsetzung verbindlich vorschreiben.
- **Technisch:** Tests in getrennter Test-/Staging-Umgebung durchführen und dokumentieren. Referenz: BL-OPS-01, BL-OPS-02 (Umgebungstrennung).
- **Typische Nachweise:** Testprotokolle, Rollout-Plan.
- **Vorlage:** R10; VA-04; BL-OPS-02
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.1-S4 — [SOLL]
**Anforderung:** Verfahren zum Rückfall (Fallback) in Fehlerfällen werden berücksichtigt.
- **Organisatorisch:** Für jede relevante Änderung Rollback-/Fallback-Plan fordern.
- **Technisch:** Backups/Snapshots vor Change, dokumentierte Rücksetzschritte. Referenz: BL-OPS-01, BL-OPS-05 (Backup).
- **Typische Nachweise:** Rollback-Plan im Change, Snapshot-/Backup-Nachweis.
- **Vorlage:** R10; VA-04; BL-OPS-05
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.1-H1 — [HOCH]
**Anforderung:** Die Einhaltung der Informationssicherheitsanforderungen wird während und nach den Änderungen überprüft. (C, I, A)
- **Organisatorisch:** Post-Implementation-Review mit Sicherheitsprüfung verbindlich etablieren.
- **Technisch:** Konfigurations-/Compliance-Checks nach dem Change (z. B. Baseline-Scan, Hardening-Verifikation) durchführen. Referenz: BL-OPS-01.
- **Typische Nachweise:** PIR-Protokolle, Post-Change-Scan-Ergebnisse.
- **Vorlage:** R10; VA-04
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 5.2.2 — Trennung von Entwicklungs-, Test- und Produktivumgebungen
### 5.2.2-M1 — [MUSS]
**Anforderung:** Die IT-Systeme wurden einer Risikobewertung zur Notwendigkeit der Trennung in Entwicklungs-, Test- und Produktivsysteme unterzogen.
- **Organisatorisch:** Systeme identifizieren, bei denen Entwicklung/Test/Produktion getrennt werden muss, und Ergebnis dokumentieren.
- **Technisch:** Zuordnung der Systeme zu Umgebungen im Inventar; Risikobewertung mit Verfahren VA-09 verknüpfen. Referenz: BL-OPS-02 (Umgebungstrennung).
- **Typische Nachweise:** Risikobewertung Umgebungstrennung, System-/Umgebungszuordnung.
- **Vorlage:** R10; BL-OPS-02
- **Ressourcen:** IT-Betrieb + ISB; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.2-M2 — [MUSS]
**Anforderung:** Eine Segmentierung ist auf Basis der Ergebnisse der Risikoanalyse umgesetzt.
- **Organisatorisch:** Trennung organisatorisch absichern (getrennte Berechtigungen, kein Produktivzugriff aus Testkontext).
- **Technisch:** Umgebungen netz-/systemseitig trennen (getrennte Netzsegmente, Instanzen, Zugriffsrechte). Referenz: BL-OPS-02, BL-NET-01 (Segmentierung).
- **Typische Nachweise:** Netz-/Systemtrennungsnachweis, Berechtigungskonzept je Umgebung.
- **Vorlage:** R10; BL-OPS-02; BL-NET-01
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.2-S1 — [SOLL]
**Anforderung:** Die Anforderungen an Entwicklungs- und Testumgebungen sind bestimmt und erfüllt.
- **Organisatorisch:** Vorgaben für Dev-/Test-Umgebungen festlegen (Datenherkunft, Zugriff, Löschung, keine Produktivgeheimnisse).
- **Technisch:** Härtung der Testsysteme, anonymisierte Testdaten, getrennte Zugangsdaten. Referenz: BL-OPS-02.
- **Typische Nachweise:** Vorgaben Dev/Test, Nachweis Testdaten-Anonymisierung.
- **Vorlage:** R10; BL-OPS-02
- **Ressourcen:** IT-Betrieb/Entwicklung; gering–mittel.
- **AL-Filter:** AL2 + AL3
## Control 5.2.3 — Schutz vor Schadsoftware
### 5.2.3-M1 — [MUSS]
**Anforderung:** Anforderungen zum Schutz vor Schadsoftware sind bestimmt.
- **Organisatorisch:** Richtlinie/Vorgaben zum Malware-Schutz für alle Systemtypen (Client, Server, mobile Geräte, OT) festlegen.
- **Technisch:** Schutzbedarf je Systemklasse bestimmen und Schutzmechanismen zuordnen. Referenz: BL-OPS-03 (Malware-Schutz).
- **Typische Nachweise:** Malware-Schutz-Vorgabe, Systemklassen-Zuordnung.
- **Vorlage:** R10; BL-OPS-03
- **Ressourcen:** ISB + IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.3-M2 — [MUSS]
**Anforderung:** Technische und organisatorische Maßnahmen zum Schutz vor Schadsoftware sind definiert und umgesetzt.
- **Organisatorisch:** Kombination aus Nutzerverhalten (keine unbekannte Software, Umgang mit Anhängen) und technischen Kontrollen festlegen.
- **Technisch:** Endpoint-Protection/EDR flächendeckend, zentrale Verwaltung, Application-Control. Referenz: BL-OPS-03.
- **Typische Nachweise:** AV/EDR-Deployment-Report, Richtlinie, Konfiguration.
- **Vorlage:** R10; BL-OPS-03
- **Ressourcen:** Endpoint-Protection/EDR (Beschaffung/Lizenz möglich); mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.3-S1 — [SOLL]
**Anforderung:** Unnötige Netzwerkdienste sind deaktiviert.
- **Organisatorisch:** Vorgabe zur Minimierung von Diensten (Härtung) je Systemrolle.
- **Technisch:** Systemhärtung nach Baseline, nicht benötigte Dienste/Ports schließen. Referenz: BL-OPS-03, BL-NET-02 (Dienst-/Portfreigaben).
- **Typische Nachweise:** Härtungsbaseline, Port-/Dienste-Scan.
- **Vorlage:** R10; BL-NET-02
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.3-S2 — [SOLL]
**Anforderung:** Der Zugriff auf Netzwerkdienste ist durch geeignete Schutzmaßnahmen auf das Notwendige beschränkt.
- **Organisatorisch:** Least-Privilege für Netzdienste vorgeben.
- **Technisch:** Firewall-/ACL-Regeln, Host-Firewalls, Segmentierung. Referenz: BL-NET-02, BL-NET-01.
- **Typische Nachweise:** Firewall-Regelwerk, ACL-Auszug.
- **Vorlage:** R10; BL-NET-02
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.3-S3 — [SOLL]
**Anforderung:** Schutzsoftware gegen Schadsoftware ist installiert und wird regelmäßig automatisch aktualisiert.
- **Organisatorisch:** Aktualitäts-/Abdeckungsvorgabe für Schutzsoftware festlegen.
- **Technisch:** Automatische Signatur-/Engine-Updates, zentrales Reporting über Abdeckung und Update-Stand. Referenz: BL-OPS-03.
- **Typische Nachweise:** Update-/Abdeckungsreport, Konfiguration Auto-Update.
- **Vorlage:** R10; BL-OPS-03
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.3-S4 — [SOLL]
**Anforderung:** Empfangene Dateien und Software werden vor Ausführung automatisch geprüft (On-Access-Scan).
- **Organisatorisch:** On-Access-Scan verbindlich vorgeben.
- **Technisch:** Echtzeitschutz/On-Access-Scanning aktivieren und gegen Deaktivierung schützen. Referenz: BL-OPS-03.
- **Typische Nachweise:** Konfigurationsnachweis Echtzeitschutz.
- **Vorlage:** R10; BL-OPS-03
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.3-S5 — [SOLL]
**Anforderung:** Der gesamte Datenbestand aller Systeme wird regelmäßig auf Schadsoftware geprüft.
- **Organisatorisch:** Turnus für vollständige Scans festlegen.
- **Technisch:** Geplante Full-Scans zentral steuern und auswerten. Referenz: BL-OPS-03.
- **Typische Nachweise:** Scan-Zeitpläne, Scan-Berichte.
- **Vorlage:** R10; BL-OPS-03
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.3-S6 — [SOLL]
**Anforderung:** Über zentrale Gateways übertragene Daten werden automatisch durch Schutzsoftware geprüft.
- **Organisatorisch:** Prüfung an E-Mail-/Web-/Übergabe-Gateways verpflichtend festlegen.
- **Technisch:** Gateway-Scanning (Mail-Security, Web-Proxy/Sandbox) einsetzen. Referenz: BL-OPS-03, BL-NET-02.
- **Typische Nachweise:** Gateway-Konfiguration, Scan-Statistik.
- **Vorlage:** R10; BL-OPS-03
- **Ressourcen:** Mail-/Web-Security-Gateway (Beschaffung möglich); mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.3-S7 — [SOLL]
**Anforderung:** Maßnahmen, die verhindern, dass Schutzsoftware durch Nutzer deaktiviert oder verändert wird, sind umgesetzt.
- **Organisatorisch:** Verbot der Deaktivierung in der Richtlinie verankern.
- **Technisch:** Tamper-Protection, Entzug lokaler Admin-Rechte, zentrale Richtlinienbindung. Referenz: BL-OPS-03, BL-IAM-05 (Privilegien).
- **Typische Nachweise:** Tamper-Protection-Konfiguration, Rechtekonzept.
- **Vorlage:** R10; BL-OPS-03; BL-IAM-05
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.3-S8 — [SOLL]
**Anforderung:** Für IT-Systeme ohne Schutzsoftware sind alternative Maßnahmen umgesetzt.
- **Organisatorisch:** Systeme ohne AV (z. B. OT, Appliances) identifizieren und Ersatzmaßnahmen festlegen.
- **Technisch:** Netzisolation, Application-Whitelisting, minimale Dienste, erhöhte Resilienz. Referenz: BL-OPS-03, BL-NET-01.
- **Typische Nachweise:** Liste betroffener Systeme mit kompensierenden Maßnahmen.
- **Vorlage:** R10; BL-NET-01
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL2 + AL3
## Control 5.2.4 — Ereignisprotokollierung (Logging & Monitoring)
### 5.2.4-M1 — [MUSS]
**Anforderung:** Informationssicherheitsanforderungen an den Umgang mit Ereignisprotokollen sind bestimmt und erfüllt.
- **Organisatorisch:** Logging-Konzept mit Umfang, Aufbewahrungsfristen, Zugriff, Datenschutz-/Mitbestimmungsvorgaben definieren.
- **Technisch:** Zentrale Protokollierung (SIEM/Log-Management), definierte Log-Quellen und Retention. Referenz: BL-OPS-04 (Logging/Retention).
- **Typische Nachweise:** Logging-Konzept, Aufbewahrungsvorgabe, Log-Quellenliste.
- **Vorlage:** R10; VA-13; BL-OPS-04
- **Ressourcen:** IT-Betrieb; ggf. SIEM/Log-Management (Beschaffung möglich); mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.4-M2 — [MUSS]
**Anforderung:** Sicherheitsrelevante Anforderungen an die Protokollierung von Administrator- und Nutzeraktivitäten sind bestimmt und erfüllt.
- **Organisatorisch:** Festlegen, welche Admin-/Nutzeraktionen (Logins, Rechteänderungen, privilegierte Aktionen) protokolliert werden; Mitbestimmung/Datenschutz einbinden.
- **Technisch:** Audit-Logging auf Systemen und für privilegierte Zugriffe (PAM) aktivieren. Referenz: BL-OPS-04, BL-IAM-05.
- **Typische Nachweise:** Log-Auszüge Admin-Aktivitäten, Audit-Policy-Konfiguration.
- **Vorlage:** R10; VA-13; BL-OPS-04
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.4-M3 — [MUSS]
**Anforderung:** Die eingesetzten IT-Systeme werden hinsichtlich der Notwendigkeit der Protokollierung bewertet.
- **Organisatorisch:** Bewertungskriterien festlegen, welche Systeme protokolliert werden müssen.
- **Technisch:** Logging-Abdeckung je System dokumentieren und aus dem Asset-Inventar ableiten. Referenz: BL-OPS-04.
- **Typische Nachweise:** Bewertungsübersicht Protokollierungsbedarf.
- **Vorlage:** R10; VA-13
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.4-M4 — [MUSS]
**Anforderung:** Bei Nutzung externer IT-Dienste werden Informationen zu den Überwachungsmöglichkeiten eingeholt und berücksichtigt.
- **Organisatorisch:** Bei Cloud-/Dienstauswahl Logging-/Audit-Fähigkeiten abfragen und vertraglich sichern.
- **Technisch:** Verfügbare Anbieter-Logs (Audit-Logs, Access-Logs) anbinden/exportieren. Referenz: BL-OPS-04.
- **Typische Nachweise:** Anbieterauskunft Monitoring, angebundene Cloud-Logs.
- **Vorlage:** R10; VA-13
- **Ressourcen:** IT-Betrieb/Einkauf; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.4-M5 — [MUSS]
**Anforderung:** Ereignisprotokolle werden regelmäßig auf Richtlinienverstöße und auffällige Probleme geprüft.
- **Organisatorisch:** Auswerteturnus und Verantwortliche festlegen; rechtliche/organisatorische Vorgaben (Datenschutz, Mitbestimmung) einhalten.
- **Technisch:** Regelbasierte Auswertung/Alerting im SIEM, Use-Cases für auffällige Ereignisse. Referenz: BL-OPS-04.
- **Typische Nachweise:** Auswerteprotokolle, SIEM-Alert-Regeln, Reports.
- **Vorlage:** R10; VA-13
- **Ressourcen:** IT-Betrieb/Security-Analyse; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.4-S1 — [SOLL]
**Anforderung:** Ein Verfahren zur Eskalation relevanter Ereignisse an die verantwortliche Stelle ist definiert und etabliert.
- **Organisatorisch:** Eskalationswege und Reaktionszuständigkeiten festlegen (Anbindung an Incident-Prozess R04).
- **Technisch:** Automatisierte Alerts an definierte Empfänger/Ticketsystem. Referenz: BL-OPS-04.
- **Typische Nachweise:** Eskalationsverfahren, Alert-Routing, Ticket-Nachweise.
- **Vorlage:** R10; VA-13; VA-01
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.4-S2 — [SOLL]
**Anforderung:** Ereignisprotokolle sind gegen Veränderung geschützt.
- **Organisatorisch:** Vorgabe zur Integrität und Zugriffsbeschränkung der Logs.
- **Technisch:** Zentrale, schreibgeschützte/WORM-Logablage, getrennte Log-Umgebung, Zugriffskontrolle. Referenz: BL-OPS-04.
- **Typische Nachweise:** Konfiguration Log-Integritätsschutz, Zugriffskonzept Log-System.
- **Vorlage:** R10; BL-OPS-04
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.4-S3 — [SOLL]
**Anforderung:** Eine angemessene Überwachung und Aufzeichnung aller informationssicherheitsrelevanten Aktionen im Netzwerk ist etabliert.
- **Organisatorisch:** Umfang der Netzüberwachung festlegen.
- **Technisch:** Netzwerk-Monitoring/IDS/NDR, zentrale Aufzeichnung sicherheitsrelevanter Netzereignisse. Referenz: BL-NET-01, BL-OPS-04.
- **Typische Nachweise:** IDS/NDR-Konfiguration, Monitoring-Reports.
- **Vorlage:** R10; BL-NET-01
- **Ressourcen:** IDS/NDR-Lösung (Beschaffung möglich); mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.4-H1 — [HOCH]
**Anforderung:** Sicherheitsrelevante Anforderungen an den Umgang mit Ereignisprotokollen (z. B. vertragliche) sind bestimmt und umgesetzt. (C, I, A)
- **Organisatorisch:** Kunden-/vertragliche Log-Anforderungen erheben und umsetzen (z. B. Aufbewahrung, Bereitstellung).
- **Technisch:** Erweiterte Retention, kundenspezifische Log-Trennung/-Bereitstellung. Referenz: BL-OPS-04.
- **Typische Nachweise:** Mapping vertragliche Anforderungen↔Umsetzung, Retention-Konfiguration.
- **Vorlage:** R10; BL-OPS-04
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.4-H2 — [HOCH]
**Anforderung:** Ereignisse zu Auf- und Abbau von Fernzugriffssitzungen werden protokolliert. (C, I, A)
- **Organisatorisch:** Protokollierungspflicht für Fernwartung/Fernzugriff festlegen.
- **Technisch:** Session-Logging in VPN/PAM/Fernwartungslösung, inkl. Start-/Endzeit und Nutzer. Referenz: BL-NET-03, BL-OPS-04.
- **Typische Nachweise:** Fernzugriffs-Session-Logs, PAM-Aufzeichnungen.
- **Vorlage:** R10; BL-NET-03
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.4-V1 — [SEHR HOCH]
**Anforderung:** Protokollierung jedes Zugriffs auf Daten mit sehr hohem Schutzbedarf, soweit technisch/rechtlich zulässig. (C, I)
- **Organisatorisch:** Zugriffsprotokollierung für sehr hohe Schutzklasse verbindlich festlegen; Datenschutz-/Mitbestimmung klären.
- **Technisch:** Objekt-/Datenzugriffs-Auditing (File-/DB-Access-Logs) für die betreffenden Datenbestände aktivieren. Referenz: BL-OPS-04.
- **Typische Nachweise:** Data-Access-Logs, Konfiguration Objekt-Auditing.
- **Vorlage:** R10; BL-OPS-04
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 5.2.5 — Umgang mit technischen Schwachstellen (Vulnerability & Patch Management)
### 5.2.5-M1 — [MUSS]
**Anforderung:** Informationen über technische Schwachstellen der eingesetzten IT-Systeme werden erhoben.
- **Organisatorisch:** Quellen definieren (Herstellermeldungen, CVE/CERT-Feeds, Audits) und Verantwortliche für die Auswertung benennen.
- **Technisch:** Abgleich von Schwachstelleninfos mit Asset-Inventar; automatisierte Vulnerability-Feeds/Scanner. Referenz: BL-OPS-06 (Patch-/Schwachstellenmanagement).
- **Typische Nachweise:** Abonnierte Feeds/CERT-Meldungen, Schwachstellenliste, Scan-Reports.
- **Vorlage:** R10; VA-04; VA-06; BL-OPS-06
- **Ressourcen:** IT-Betrieb; ggf. Vulnerability-Scanner (Beschaffung möglich); mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.5-M2 — [MUSS]
**Anforderung:** Potenziell betroffene IT-Systeme/Software werden identifiziert und das Risiko bewertet.
- **Organisatorisch:** Bewertungsprozess (Kritikalität, CVSS, Betroffenheit) mit Fristen etablieren.
- **Technisch:** Verknüpfung Schwachstelle↔Asset, Priorisierung nach Schweregrad/Exponiertheit. Referenz: BL-OPS-06.
- **Typische Nachweise:** Risikobewertungen je Schwachstelle, Priorisierungsliste.
- **Vorlage:** R10; VA-06; BL-OPS-06
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.5-M3 — [MUSS]
**Anforderung:** Risiken aus Schwachstellen werden behandelt.
- **Organisatorisch:** Behandlungsentscheidung (Patch, Mitigation, Akzeptanz) dokumentieren und nachverfolgen.
- **Technisch:** Umsetzung von Patches/Workarounds, Nachkontrolle. Referenz: BL-OPS-06.
- **Typische Nachweise:** Maßnahmen-/Behandlungsnachweise, Ticket-Historie.
- **Vorlage:** R10; VA-06; BL-OPS-06
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.5-S1 — [SOLL]
**Anforderung:** Ein angemessenes Patch-Management ist definiert und umgesetzt.
- **Organisatorisch:** Patch-Prozess mit Test-, Freigabe- und Fristenregelung (nach Kritikalität) festlegen.
- **Technisch:** Patch-Management-Werkzeug mit Verteilung, Test-Ring und Reporting. Referenz: BL-OPS-06.
- **Typische Nachweise:** Patch-Richtlinie, Patch-Reports/Compliance-Grad.
- **Vorlage:** R10; VA-06; BL-OPS-06
- **Ressourcen:** Patch-Management-Tool (Beschaffung möglich); mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.5-S2 — [SOLL]
**Anforderung:** Risikominimierende Maßnahmen werden bei Bedarf umgesetzt.
- **Organisatorisch:** Für nicht sofort patchbare Schwachstellen kompensierende Maßnahmen festlegen.
- **Technisch:** Virtual Patching (IPS/WAF), Isolation, Dienstabschaltung. Referenz: BL-OPS-06, BL-NET-02.
- **Typische Nachweise:** Dokumentierte Mitigationsmaßnahmen.
- **Vorlage:** R10; BL-OPS-06
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.5-S3 — [SOLL]
**Anforderung:** Die erfolgreiche Installation von Patches wird verifiziert.
- **Organisatorisch:** Verifikationsschritt im Patch-Prozess vorsehen.
- **Technisch:** Compliance-Reports/Re-Scan zur Bestätigung des Patch-Stands. Referenz: BL-OPS-06.
- **Typische Nachweise:** Patch-Compliance-Report, Verifikations-Scan.
- **Vorlage:** R10; BL-OPS-06
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
## Control 5.2.6 — Prüfung (Audit) von IT-Systemen und -Diensten
### 5.2.6-M1 — [MUSS]
**Anforderung:** Anforderungen an die Prüfung (Audit) von IT-Systemen oder -Diensten sind bestimmt.
- **Organisatorisch:** Prüfumfang, -kriterien und -verantwortliche festlegen (technische Systemprüfungen/Security-Tests).
- **Technisch:** Prüfmethoden je Systemklasse definieren (Konfigurationsprüfung, Schwachstellenscan). Referenz: BL-OPS-07 (Systemprüfung/Scanning).
- **Typische Nachweise:** Prüfkonzept/-vorgaben, Prüfkriterien.
- **Vorlage:** R10; VA-06; BL-OPS-07
- **Ressourcen:** IT-Betrieb/ISB; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.6-M2 — [MUSS]
**Anforderung:** Der Umfang der Systemprüfung wird rechtzeitig festgelegt.
- **Organisatorisch:** Scope und Zeitpunkt vorab abstimmen und dokumentieren.
- **Technisch:** Zieldefinition (Systeme, Tiefe, Werkzeuge) vor Prüfbeginn. Referenz: BL-OPS-07.
- **Typische Nachweise:** Scope-Dokument, Prüfplan.
- **Vorlage:** R10; VA-06
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.6-M3 — [MUSS]
**Anforderung:** System-/Dienstprüfungen werden mit Betreiber und Nutzern abgestimmt.
- **Organisatorisch:** Abstimmungs-/Genehmigungsprozess vor Prüfungen (Vermeidung von Betriebsstörungen) etablieren.
- **Technisch:** Prüffenster/Wartungsfenster planen. Referenz: BL-OPS-07.
- **Typische Nachweise:** Abstimmungsnachweis, Freigabe der Prüfung.
- **Vorlage:** R10; VA-06
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.6-M4 — [MUSS]
**Anforderung:** Die Ergebnisse werden nachvollziehbar gespeichert und der Leitung berichtet.
- **Organisatorisch:** Berichts- und Ablagepflicht festlegen.
- **Technisch:** Zentrale, zugriffsgeschützte Ablage der Prüfberichte. Referenz: BL-OPS-07.
- **Typische Nachweise:** Prüfberichte, Berichtsvermerk an Leitung.
- **Vorlage:** R10; VA-06
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.6-M5 — [MUSS]
**Anforderung:** Aus den Ergebnissen werden Maßnahmen abgeleitet und fristgerecht umgesetzt.
- **Organisatorisch:** Maßnahmenverfolgung mit Fristen und Verantwortlichen etablieren.
- **Technisch:** Findings in Maßnahmen-/Ticketsystem überführen und nachhalten. Referenz: BL-OPS-06, BL-OPS-07.
- **Typische Nachweise:** Maßnahmenplan, Umsetzungsnachweise.
- **Vorlage:** R10; VA-06
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.6-S1 — [SOLL]
**Anforderung:** Prüfungen werden unter Berücksichtigung möglicher Sicherheitsrisiken geplant.
- **Organisatorisch:** Risiken der Prüfung selbst (Störungen, Datenzugriff) vorab bewerten.
- **Technisch:** Schonende Testmodi, Testumgebung bei kritischen Systemen. Referenz: BL-OPS-07.
- **Typische Nachweise:** Prüfplanung mit Risikobetrachtung.
- **Vorlage:** R10; VA-06
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.6-S2 — [SOLL]
**Anforderung:** Regelmäßige System-/Dienstprüfungen werden durchgeführt.
- **Organisatorisch:** Prüfturnus festlegen.
- **Technisch:** Wiederkehrende Scans/Audits automatisieren. Referenz: BL-OPS-07.
- **Typische Nachweise:** Prüfkalender, wiederkehrende Prüfberichte.
- **Vorlage:** R10; VA-06
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.6-S3 — [SOLL]
**Anforderung:** Innerhalb angemessener Frist wird ein Prüfbericht erstellt.
- **Organisatorisch:** Berichtsfrist festlegen.
- **Technisch:** Standardisierte Berichtsvorlage/Report-Export. Referenz: BL-OPS-07.
- **Typische Nachweise:** Datierte Prüfberichte.
- **Vorlage:** R10; VA-06
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.6-H1 — [HOCH]
**Anforderung:** Für kritische IT-Systeme/-Dienste sind zusätzliche Prüfanforderungen identifiziert und werden erfüllt. (A)
- **Organisatorisch:** Kritische Systeme bestimmen und erweiterte Prüftiefe/-intervalle festlegen.
- **Technisch:** Dienstspezifische Tests und/oder manuelle Penetrationstests, risikobasierte Intervalle. Referenz: BL-OPS-07.
- **Typische Nachweise:** Pentest-/Prüfberichte kritischer Systeme, Intervallfestlegung.
- **Vorlage:** R10; VA-06; BL-OPS-07
- **Ressourcen:** ggf. externer Pentest-Dienstleister (Budget); mittel–hoch.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.6-V1 — [SEHR HOCH]
**Anforderung:** IT-Systeme/-Dienste werden regelmäßig auf Schwachstellen gescannt; nicht scanbare Systeme erhalten Schutzmaßnahmen. (C, I, A)
- **Organisatorisch:** Verbindlichen Scan-Turnus und Umgang mit nicht scanbaren Systemen festlegen.
- **Technisch:** Regelmäßige authentifizierte Vulnerability-Scans; für nicht scanbare Systeme Isolation/kompensierende Maßnahmen. Referenz: BL-OPS-07, BL-OPS-06.
- **Typische Nachweise:** Scan-Reports, Liste nicht scanbarer Systeme mit Ersatzmaßnahmen.
- **Vorlage:** R10; VA-06; BL-OPS-07
- **Ressourcen:** Vulnerability-Scanner (Beschaffung möglich); mittel.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 5.2.7 — Netzwerkmanagement und -segmentierung
### 5.2.7-M1 — [MUSS]
**Anforderung:** Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und erfüllt.
- **Organisatorisch:** Netzwerkbetriebsvorgaben (Verantwortliche, Konfigurations-/Änderungsregeln, Dokumentationspflicht) festlegen.
- **Technisch:** Zentrale Verwaltung der Netzkomponenten, gehärtete Konfigurationen, Netzdokumentation. Referenz: BL-NET-01 (Netzwerkmanagement/Segmentierung).
- **Typische Nachweise:** Netzbetriebsrichtlinie, Netzplan, Konfigurationsstandards.
- **Vorlage:** R10; BL-NET-01
- **Ressourcen:** IT-Betrieb/Netzwerk; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.7-M2 — [MUSS]
**Anforderung:** Anforderungen an die Netzsegmentierung sind bestimmt und erfüllt.
- **Organisatorisch:** Segmentierungsvorgaben je Schutzbedarf/Zone festlegen (z. B. Client, Server, OT, DMZ, Gäste).
- **Technisch:** VLANs/Subnetze mit Firewall-/ACL-Kontrolle zwischen Segmenten. Referenz: BL-NET-01, BL-NET-02.
- **Typische Nachweise:** Segmentierungskonzept, Firewall-Regeln zwischen Zonen.
- **Vorlage:** R10; BL-NET-01; BL-NET-02
- **Ressourcen:** IT-Betrieb/Netzwerk; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.7-S1 — [SOLL]
**Anforderung:** Verfahren für das Management und die Steuerung von Netzwerken sind definiert.
- **Organisatorisch:** Betriebs-/Änderungsverfahren für das Netzwerk dokumentieren.
- **Technisch:** Change-gebundene Netzkonfiguration, Konfigurations-Backups/Versionierung. Referenz: BL-NET-01, BL-OPS-01.
- **Typische Nachweise:** Netzbetriebsverfahren, Konfigurations-Backups.
- **Vorlage:** R10; BL-NET-01
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.7-S2 — [SOLL]
**Anforderung:** Für eine risikobasierte Netzsegmentierung werden die einschlägigen Aspekte berücksichtigt.
- **Organisatorisch:** Segmentierung anhand Risiko/Schutzbedarf und Datenflüssen begründen.
- **Technisch:** Feinere Segmentierung/Mikrosegmentierung für schützenswerte Bereiche. Referenz: BL-NET-01.
- **Typische Nachweise:** Risikobasierte Segmentierungsbegründung, Datenflussanalyse.
- **Vorlage:** R10; BL-NET-01
- **Ressourcen:** IT-Betrieb/Netzwerk; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.7-H1 — [HOCH]
**Anforderung:** Erweiterte Anforderungen an das Management und die Steuerung von Netzwerken sind bestimmt und umgesetzt. (C, I, A)
- **Organisatorisch:** Erhöhte Kontrollen für kritische Netzbereiche festlegen (z. B. dediziertes Admin-Netz, strengere Änderungsfreigaben).
- **Technisch:** Out-of-Band-Management, NAC/Portsicherheit, verschlüsseltes Management, Monitoring. Referenz: BL-NET-01, BL-NET-02.
- **Typische Nachweise:** NAC-/Admin-Netz-Konfiguration, Management-Härtung.
- **Vorlage:** R10; BL-NET-01
- **Ressourcen:** IT-Betrieb/Netzwerk; mittel–hoch.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 5.2.8 — Kontinuität kritischer IT-Dienste (IT-Notfall-/BCM)
### 5.2.8-M1 — [MUSS]
**Anforderung:** Kritische IT-Dienste sind identifiziert und die Geschäftsauswirkung wird berücksichtigt.
- **Organisatorisch:** Business-Impact-Analyse durchführen, kritische IT-Dienste und Abhängigkeiten bestimmen.
- **Technisch:** Kritikalitätsattribute im Service-/Asset-Inventar pflegen. Referenz: BL-OPS-08 (Kontinuität/BCM).
- **Typische Nachweise:** BIA, Liste kritischer IT-Dienste.
- **Vorlage:** R04; VA-02; BL-OPS-08
- **Ressourcen:** ISB/IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.8-M2 — [MUSS]
**Anforderung:** Anforderungen und Verantwortlichkeiten für Kontinuität und Wiederherstellung sind bekannt und erfüllt.
- **Organisatorisch:** Verantwortliche und Kontinuitätsanforderungen (Zielzustände, Zuständigkeiten) festlegen und kommunizieren.
- **Technisch:** Wiederherstellungsverfahren je kritischem Dienst dokumentieren. Referenz: BL-OPS-08, BL-OPS-05.
- **Typische Nachweise:** Rollen-/Verantwortungsmatrix, Kontinuitätsanforderungen je Dienst.
- **Vorlage:** R04; VA-02; BL-OPS-08
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.8-S1 — [SOLL]
**Anforderung:** Kritische IT-Systeme sind identifiziert.
- **Organisatorisch:** Neben Diensten auch die unterstützenden kritischen Systeme/Komponenten bestimmen.
- **Technisch:** Abhängigkeitskarte Dienst↔System pflegen. Referenz: BL-OPS-08.
- **Typische Nachweise:** Liste kritischer Systeme, Abhängigkeitsdiagramm.
- **Vorlage:** R04; VA-02
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.2.8-S2 — [SOLL]
**Anforderung:** Eine Kontinuitätsplanung existiert und wird regelmäßig überprüft und aktualisiert.
- **Organisatorisch:** IT-Notfallplan/BCP erstellen und Review-Turnus festlegen.
- **Technisch:** Wiederanlaufpläne, Notfallkonfigurationen dokumentieren und pflegen. Referenz: BL-OPS-08.
- **Typische Nachweise:** IT-Notfallplan, Review-Historie.
- **Vorlage:** R04; VA-02; BL-OPS-08
- **Ressourcen:** ISB/IT-Betrieb; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.8-S3 — [SOLL]
**Anforderung:** Die Kontinuitätsplanung umfasst mindestens (D)DoS, Ransomware/Sabotage, Systemausfall und Naturkatastrophen.
- **Organisatorisch:** Szenariokatalog festlegen und Maßnahmen je Szenario planen.
- **Technisch:** Szenariospezifische Vorkehrungen (DDoS-Schutz, Ransomware-Wiederanlauf aus sauberem Backup, Redundanz). Referenz: BL-OPS-08, BL-OPS-05.
- **Typische Nachweise:** Szenarienübersicht mit Maßnahmen.
- **Vorlage:** R04; VA-02
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.8-H1 — [HOCH]
**Anforderung:** Die Kontinuitätsplanung enthält vordefinierte Zeitrahmen (RTO) für den Wiederanlauf. (A)
- **Organisatorisch:** RTO (und ergänzend RPO) je kritischem Dienst festlegen und freigeben.
- **Technisch:** Wiederherstellungsverfahren auf RTO auslegen (Ressourcen, Automatisierung). Referenz: BL-OPS-08, BL-OPS-05.
- **Typische Nachweise:** RTO/RPO-Festlegung, Abgleich mit Wiederanlaufverfahren.
- **Vorlage:** R04; VA-02; BL-OPS-08
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.8-H2 — [HOCH]
**Anforderung:** Angemessene SLAs mit externen Dienstleistern entsprechend der Kontinuitätsplanung bestehen. (A)
- **Organisatorisch:** Kontinuitäts-/Wiederherstellungszusagen vertraglich (SLA) mit Providern vereinbaren.
- **Technisch:** SLA-Parameter (Verfügbarkeit, Reaktions-/Wiederherstellzeit) mit eigenen RTO abgleichen. Referenz: BL-OPS-08.
- **Typische Nachweise:** SLA-Verträge, Abgleich SLA↔RTO.
- **Vorlage:** R04; VA-02
- **Ressourcen:** Einkauf/IT; gering.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.8-H3 — [HOCH]
**Anforderung:** Die Kontinuitätspläne umfassen die Koordination vertraglich vereinbarter Kommunikation mit Geschäftspartnern. (A)
- **Organisatorisch:** Kommunikations-/Meldepflichten gegenüber Kunden/Partnern im Notfall festlegen.
- **Technisch:** Kontaktlisten und Kommunikationskanäle notfallfest bereithalten. Referenz: BL-OPS-08.
- **Typische Nachweise:** Kommunikationsplan, Kontaktverzeichnis.
- **Vorlage:** R04; VA-02
- **Ressourcen:** ISB/IT; gering.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.8-H4 — [HOCH]
**Anforderung:** Die Kontinuitätsplanung wird regelmäßig getestet (inkl. vollständiger Wiederherstellung und Zielzeiten). (A)
- **Organisatorisch:** Testturnus und Testszenarien festlegen, Ergebnisse auswerten.
- **Technisch:** Wiederherstellungstests bis in bekannten Zustand, RTO-Messung. Referenz: BL-OPS-08, BL-OPS-05.
- **Typische Nachweise:** Testprotokolle mit Zielzeiterreichung, Lessons Learned.
- **Vorlage:** R04; VA-02
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.8-H5 — [HOCH]
**Anforderung:** Eine Backup- und Wiederherstellungsstrategie für kritische IT-Dienste ist definiert und umgesetzt. (C, I, A)
- **Organisatorisch:** Backup-Strategie (Umfang, Frequenz, Aufbewahrung, Schutzziele) für kritische Dienste festlegen.
- **Technisch:** Regelmäßige, überwachte Backups mit Verschlüsselung und getrennter Ablage. Referenz: BL-OPS-05 (Backup).
- **Typische Nachweise:** Backup-Konzept, Backup-Reports.
- **Vorlage:** R04; VA-02; BL-OPS-05
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.8-H6 — [HOCH]
**Anforderung:** Backups kritischer IT-Dienste sind gegen unbefugte Veränderung/Löschung durch Schadsoftware geschützt. (I, A)
- **Organisatorisch:** Schutzanforderung gegen Ransomware-Zugriff auf Backups festschreiben.
- **Technisch:** Immutable/WORM-Backups, Offline-/Air-Gap-Kopie, getrennte Backup-Credentials. Referenz: BL-OPS-05.
- **Typische Nachweise:** Immutable-/Offline-Backup-Konfiguration.
- **Vorlage:** R04; BL-OPS-05
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.8-H7 — [HOCH]
**Anforderung:** Backups kritischer IT-Dienste sind gegen unbefugten Zugriff durch Schadsoftware oder Betreiber geschützt. (C, I)
- **Organisatorisch:** Vertraulichkeitsschutz für Backups (auch bei externem Betrieb) festlegen.
- **Technisch:** Verschlüsselung der Backups mit eigener Schlüsselhoheit, strikte Zugriffstrennung. Referenz: BL-OPS-05, BL-CRY-03.
- **Typische Nachweise:** Backup-Verschlüsselung, Zugriffskonzept.
- **Vorlage:** R04; BL-OPS-05; BL-CRY-03
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.8-V1 — [SEHR HOCH]
**Anforderung:** Die Kontinuitätsplanung ist mit den Kontinuitätsplänen relevanter externer Dienstleister abgestimmt. (A)
- **Organisatorisch:** Gemeinsame Abstimmung/Verzahnung der BCM-Pläne mit kritischen Providern.
- **Technisch:** End-to-End-Wiederanlaufketten über Provider hinweg dokumentieren. Referenz: BL-OPS-08.
- **Typische Nachweise:** Abgestimmte BCM-Pläne, Provider-Bestätigungen.
- **Vorlage:** R04; VA-02
- **Ressourcen:** ISB/Einkauf; mittel.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
### 5.2.8-V2 — [SEHR HOCH]
**Anforderung:** Fortführung wesentlicher Kern-/Geschäftsfunktionen mit minimalem Verlust an Betriebskontinuität ist möglich.
- **Organisatorisch:** Notbetriebskonzepte für Kernfunktionen definieren.
- **Technisch:** Hochverfügbarkeit/Redundanz und Failover für Kernfunktionen. Referenz: BL-OPS-08.
- **Typische Nachweise:** Notbetriebs-/HA-Konzept, Failover-Nachweis.
- **Vorlage:** R04; VA-02
- **Ressourcen:** IT-Betrieb; hoch.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
### 5.2.8-V3 — [SEHR HOCH]
**Anforderung:** Die Kontinuitätsplanung wird regelmäßig getestet; Szenarien, Ergebnisse und Lessons Learned werden aufgezeichnet. (I, A)
- **Organisatorisch:** Umfassendes Testprogramm mit Dokumentationspflicht etablieren.
- **Technisch:** Realitätsnahe Failover-/Wiederherstellungstests, Auswertung und Nachsteuerung. Referenz: BL-OPS-08.
- **Typische Nachweise:** Testberichte mit Szenarien und Lessons Learned.
- **Vorlage:** R04; VA-02
- **Ressourcen:** IT-Betrieb; mittel–hoch.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 5.2.9 — Datensicherung und Wiederherstellung (Backup)
### 5.2.9-M1 — [MUSS]
**Anforderung:** Backup-Konzepte existieren für relevante IT-Systeme; Schutzmaßnahmen für C/I/A der Sicherungen werden berücksichtigt.
- **Organisatorisch:** Backup-Konzept je System/Datenbestand (Umfang, Frequenz, Aufbewahrung, Verantwortliche) erstellen.
- **Technisch:** Automatisierte Backups mit Verschlüsselung (C), Integritätsprüfung (I) und redundanter Ablage (A). Referenz: BL-OPS-05 (Backup).
- **Typische Nachweise:** Backup-Konzept, Backup-Job-Reports.
- **Vorlage:** R10; VA-05; BL-OPS-05
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.9-M2 — [MUSS]
**Anforderung:** Wiederherstellungskonzepte existieren für relevante IT-Dienste.
- **Organisatorisch:** Wiederherstellungsverfahren je Dienst dokumentieren (Schritte, Zuständige, Voraussetzungen).
- **Technisch:** Restore-Prozeduren mit Reihenfolge und Abhängigkeiten hinterlegen. Referenz: BL-OPS-05.
- **Typische Nachweise:** Wiederherstellungskonzept, Restore-Anleitung.
- **Vorlage:** R10; VA-05; BL-OPS-05
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.9-S1 — [SOLL]
**Anforderung:** Für jeden relevanten IT-Dienst existiert ein Backup-/Wiederherstellungskonzept inkl. Abhängigkeiten und Reihenfolge.
- **Organisatorisch:** Konzepte diensteweise vervollständigen und Wiederanlaufreihenfolge festlegen.
- **Technisch:** Abhängigkeits-/Reihenfolgeplan in Restore-Runbooks abbilden. Referenz: BL-OPS-05, BL-OPS-08.
- **Typische Nachweise:** Restore-Runbooks mit Abhängigkeitsreihenfolge.
- **Vorlage:** R10; VA-05; BL-OPS-05
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.2.9-H1 — [HOCH]
**Anforderung:** Backup-/Wiederherstellungskonzepte werden methodisch in regelmäßigen Abständen überprüft. (A)
- **Organisatorisch:** Review-Turnus für die Konzepte festlegen.
- **Technisch:** Abgleich Konzept↔tatsächliche Systemlandschaft/Backup-Jobs. Referenz: BL-OPS-05.
- **Typische Nachweise:** Review-Protokolle der Backup-Konzepte.
- **Vorlage:** R10; VA-05; BL-OPS-05
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.9-H2 — [HOCH]
**Anforderung:** Die grundsätzliche Wiederherstellbarkeit wird berücksichtigt und getestet. (I, A)
- **Organisatorisch:** Restore-Tests einplanen (Stichproben/Testsysteme).
- **Technisch:** Regelmäßige Test-Restores auf Testsystem, Integritätsprüfung der Rücksicherung. Referenz: BL-OPS-05.
- **Typische Nachweise:** Restore-Testprotokolle.
- **Vorlage:** R10; VA-05; BL-OPS-05
- **Ressourcen:** IT-Betrieb; gering–mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 5.2.9-V1 — [SEHR HOCH]
**Anforderung:** (Zusätzliche) Backups über Offline-Verfahren, immutable Backups oder isolierte IAM-Lösung. (I, A)
- **Organisatorisch:** Ransomware-resistente Backup-Linie für sehr hohen Schutzbedarf festlegen.
- **Technisch:** Air-Gap/Offline-Kopien, Immutable-Storage, getrennte/isolierte Backup-Identitäten. Referenz: BL-OPS-05.
- **Typische Nachweise:** Konfiguration Offline-/Immutable-Backup, getrennte IAM-Nachweise.
- **Vorlage:** R10; VA-05; BL-OPS-05
- **Ressourcen:** IT-Betrieb; mittel–hoch.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
### 5.2.9-V2 — [SEHR HOCH]
**Anforderung:** Wiederherstellungsverfahren werden methodisch in regelmäßigen Abständen technisch getestet. (I, A)
- **Organisatorisch:** Verbindliches Restore-Testprogramm mit Auswertung etablieren.
- **Technisch:** Vollständige technische Restore-Tests inkl. Funktionsprüfung des wiederhergestellten Dienstes. Referenz: BL-OPS-05.
- **Typische Nachweise:** Technische Restore-Testberichte.
- **Vorlage:** R10; VA-05; BL-OPS-05
- **Ressourcen:** IT-Betrieb; mittel.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
### 5.2.9-V3 — [SEHR HOCH]
**Anforderung:** Geografische Redundanz wird in Backup-/Wiederherstellungskonzepten berücksichtigt. (A)
- **Organisatorisch:** Vorgabe zur räumlich getrennten Aufbewahrung von Sicherungen.
- **Technisch:** Backup-Replikation an zweiten Standort/Region, georedundante Ablage. Referenz: BL-OPS-05.
- **Typische Nachweise:** Nachweis georedundanter Backup-Ablage.
- **Vorlage:** R10; VA-05; BL-OPS-05
- **Ressourcen:** IT-Betrieb; mittel–hoch.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 5.3.1 — Sichere Entwicklung und Beschaffung von IT-Diensten
### 5.3.1-M1 — [MUSS]
**Anforderung:** Die mit Design und Entwicklung eines IT-Dienstes verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.
- **Organisatorisch:** Security-by-Design im Entwicklungsprozess verankern (Sicherheitsanforderungen früh definieren, Freigaben).
- **Technisch:** Sichere Entwicklungsstandards, Threat Modeling, Code-/Konfigurationsvorgaben. Referenz: BL-OPS-02 (Umgebungstrennung), BL-CRY-01.
- **Typische Nachweise:** Sicherheitsanforderungen im Design, Secure-Development-Vorgaben.
- **Vorlage:** R11; VA-16; BL-OPS-02
- **Ressourcen:** Entwicklung/ISB; mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.1-M2 — [MUSS]
**Anforderung:** Die mit Beschaffung/Erweiterung von IT-Diensten und -Komponenten verbundenen Sicherheitsanforderungen sind bestimmt und berücksichtigt.
- **Organisatorisch:** Sicherheitsanforderungen in Beschaffungs-/Ausschreibungsprozess integrieren (Kriterien, Freigabe).
- **Technisch:** Anforderungskataloge/Sicherheitschecklisten für Beschaffung, Prüfung vor Inbetriebnahme. Referenz: BL-OPS-01.
- **Typische Nachweise:** Beschaffungsanforderungen mit Sicherheitskriterien, Freigabedokumente.
- **Vorlage:** R11; VA-16
- **Ressourcen:** Einkauf/IT/ISB; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.1-M3 — [MUSS]
**Anforderung:** Informationssicherheitsanforderungen bei Änderungen an entwickelten IT-Diensten werden berücksichtigt.
- **Organisatorisch:** Änderungen an Eigenentwicklungen an den Change-/Secure-Development-Prozess binden.
- **Technisch:** Sicherheitsprüfung/-tests bei Änderungen (SAST/DAST, Review). Referenz: BL-OPS-01, BL-OPS-02.
- **Typische Nachweise:** Change-Records mit Sicherheitsprüfung, Testresultate.
- **Vorlage:** R11; VA-16
- **Ressourcen:** Entwicklung; mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.1-M4 — [MUSS]
**Anforderung:** Systemabnahmetests werden unter Berücksichtigung der Informationssicherheitsanforderungen durchgeführt.
- **Organisatorisch:** Sicherheitskriterien als Abnahmebedingung festlegen.
- **Technisch:** Security-Testfälle in Abnahmetests, Nachweis vor Go-Live. Referenz: BL-OPS-02.
- **Typische Nachweise:** Abnahmetestprotokolle mit Sicherheitskriterien, Freigabe.
- **Vorlage:** R11; VA-16
- **Ressourcen:** Entwicklung/QA; mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.1-S1 — [SOLL]
**Anforderung:** Anforderungsspezifikationen werden erstellt.
- **Organisatorisch:** Verbindliche Spezifikation inkl. Sicherheitsanforderungen fordern.
- **Technisch:** Strukturierte Anforderungsdokumentation mit Sicherheitsabschnitt. Referenz: BL-OPS-02.
- **Typische Nachweise:** Anforderungsspezifikationen.
- **Vorlage:** R11; VA-16
- **Ressourcen:** Entwicklung; gering.
- **AL-Filter:** AL2 + AL3
### 5.3.1-S2 — [SOLL]
**Anforderung:** Anforderungsspezifikationen werden gegen die Informationssicherheitsanforderungen geprüft.
- **Organisatorisch:** Review der Spezifikation gegen Sicherheitsvorgaben etablieren.
- **Technisch:** Security-Review/Checkliste in der Spezifikationsphase. Referenz: BL-OPS-02.
- **Typische Nachweise:** Review-Vermerk, Prüfcheckliste.
- **Vorlage:** R11; VA-16
- **Ressourcen:** ISB/Entwicklung; gering.
- **AL-Filter:** AL2 + AL3
### 5.3.1-S3 — [SOLL]
**Anforderung:** Der IT-Dienst wird vor Produktivnutzung auf Einhaltung der Spezifikationen geprüft.
- **Organisatorisch:** Freigabe vor Produktivsetzung an Spezifikationskonformität binden.
- **Technisch:** Abnahme-/Konformitätstests gegen Spezifikation. Referenz: BL-OPS-02.
- **Typische Nachweise:** Konformitäts-/Abnahmeberichte.
- **Vorlage:** R11; VA-16
- **Ressourcen:** QA/Entwicklung; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.1-S4 — [SOLL]
**Anforderung:** Die Nutzung von Produktivdaten zu Testzwecken wird soweit möglich vermieden.
- **Organisatorisch:** Vorgabe zur Vermeidung von Produktivdaten in Tests; Ausnahmen genehmigungspflichtig.
- **Technisch:** Anonymisierung/Pseudonymisierung oder synthetische Testdaten. Referenz: BL-OPS-02.
- **Typische Nachweise:** Testdatenkonzept, Anonymisierungsnachweis.
- **Vorlage:** R11; VA-16
- **Ressourcen:** Entwicklung; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.1-S5 — [SOLL]
**Anforderung:** Testsysteme erhalten Schutzmaßnahmen vergleichbar zur Produktivumgebung, wenn Produktivdaten genutzt werden.
- **Organisatorisch:** Bei Produktivdaten im Test gleichwertigen Schutz vorschreiben.
- **Technisch:** Härtung, Zugriffskontrolle und Verschlüsselung der Testumgebung analog Produktion. Referenz: BL-OPS-02.
- **Typische Nachweise:** Schutzmaßnahmen-Nachweis Testumgebung.
- **Vorlage:** R11; VA-16
- **Ressourcen:** IT-Betrieb/Entwicklung; mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.1-V1 — [SEHR HOCH]
**Anforderung:** Die Sicherheit zweckgebauter/wesentlich angepasster Software wird bei Inbetriebnahme, wesentlichen Änderungen oder regelmäßig getestet. (C, I, A)
- **Organisatorisch:** Verbindliche Security-Tests (inkl. Pentest) an definierten Zeitpunkten festlegen.
- **Technisch:** Penetrationstests, SAST/DAST, Dependency-/Supply-Chain-Prüfung. Referenz: BL-OPS-07.
- **Typische Nachweise:** Pentest-/Security-Testberichte, Behebungsnachweise.
- **Vorlage:** R11; VA-16; BL-OPS-07
- **Ressourcen:** ggf. externer Pentest (Budget); mittel–hoch.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 5.3.2 — Sicherheit von Netzdiensten (Bereitstellung)
### 5.3.2-M1 — [MUSS]
**Anforderung:** Anforderungen an die Informationssicherheit von Netzdiensten sind bestimmt und erfüllt.
- **Organisatorisch:** Sicherheitsanforderungen je bereitgestelltem Netzdienst festlegen (Verschlüsselung, Auth, Verfügbarkeit).
- **Technisch:** Sichere Konfiguration der Netzdienste, Zugriffskontrolle, Verschlüsselung. Referenz: BL-NET-01, BL-CRY-02.
- **Typische Nachweise:** Sicherheitsanforderungen Netzdienste, Konfigurationsnachweise.
- **Vorlage:** R11; VA-16; BL-NET-01
- **Ressourcen:** IT-Betrieb/Netzwerk; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.2-S1 — [SOLL]
**Anforderung:** Ein Verfahren zur Absicherung und Nutzung von Netzdiensten ist definiert und umgesetzt.
- **Organisatorisch:** Betriebs-/Nutzungsverfahren für Netzdienste dokumentieren.
- **Technisch:** Standardhärtung, Monitoring und Freigabeprozess für Netzdienste. Referenz: BL-NET-01, BL-NET-02.
- **Typische Nachweise:** Netzdienst-Verfahren, Härtungsstandard.
- **Vorlage:** R11; VA-16; BL-NET-02
- **Ressourcen:** IT-Betrieb; gering.
- **AL-Filter:** AL2 + AL3
### 5.3.2-S2 — [SOLL]
**Anforderung:** Die Anforderungen werden in Form von SLAs vereinbart.
- **Organisatorisch:** Sicherheits-/Verfügbarkeitsanforderungen als SLA (intern/mit Provider) festhalten.
- **Technisch:** SLA-Parameter überwachen. Referenz: BL-NET-01.
- **Typische Nachweise:** SLA-Dokumente, SLA-Monitoring.
- **Vorlage:** R11; VA-16
- **Ressourcen:** IT/Einkauf; gering.
- **AL-Filter:** AL2 + AL3
### 5.3.2-S3 — [SOLL]
**Anforderung:** Angemessene Redundanzlösungen sind umgesetzt.
- **Organisatorisch:** Redundanzbedarf je Netzdienst festlegen.
- **Technisch:** Redundante Anbindungen/Komponenten, Failover. Referenz: BL-NET-01.
- **Typische Nachweise:** Redundanzkonzept, Failover-Nachweis.
- **Vorlage:** R11; VA-16
- **Ressourcen:** IT-Betrieb/Netzwerk; mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.2-H1 — [HOCH]
**Anforderung:** Verfahren zur Überwachung der Qualität des Netzverkehrs sind definiert und werden durchgeführt. (A)
- **Organisatorisch:** Überwachungsvorgaben (Verfügbarkeit, Qualität) festlegen.
- **Technisch:** Traffic-Flow-Analysen, Verfügbarkeits-/Latenzmessung, Alerting. Referenz: BL-NET-01.
- **Typische Nachweise:** Monitoring-Konfiguration, Qualitäts-/Verfügbarkeitsreports.
- **Vorlage:** R11; VA-16; BL-NET-01
- **Ressourcen:** Netz-Monitoring-Tool (Beschaffung möglich); mittel.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 5.3.3 — Beendigung von IT-Dienstleistungsverhältnissen
### 5.3.3-S1 — [SOLL]
**Anforderung:** Eine Beschreibung des Beendigungsprozesses ist vorhanden, an Änderungen angepasst und vertraglich geregelt.
- **Organisatorisch:** Exit-/Offboarding-Prozess für IT-Dienste definieren (Datenrückgabe, sichere Löschung, Rechteentzug) und vertraglich verankern.
- **Technisch:** Nachweisbare Datenrückgabe/-löschung, Widerruf von Zugängen und Schnittstellen. Referenz: BL-OPS-01, BL-IAM-05.
- **Typische Nachweise:** Exit-/Beendigungskonzept, Vertragsklausel, Lösch-/Rückgabenachweis.
- **Vorlage:** R11; BL-OPS-01
- **Ressourcen:** IT/Einkauf/ISB; gering–mittel.
- **AL-Filter:** AL2 + AL3
## Control 5.3.4 — Mandantentrennung bei IT-Diensten
### 5.3.4-M1 — [MUSS]
**Anforderung:** Eine wirksame Trennung (z. B. Mandantentrennung) verhindert den Zugriff unbefugter Nutzer anderer Organisationen auf eigene Informationen.
- **Organisatorisch:** Trennungsanforderung bei geteilt genutzten (Cloud-)Diensten festlegen und beim Anbieter einfordern.
- **Technisch:** Logische/physische Mandantentrennung, getrennte Berechtigungen und ggf. Verschlüsselung mit eigener Schlüsselhoheit. Referenz: BL-NET-01, BL-CRY-03.
- **Typische Nachweise:** Nachweis Mandantentrennung (Anbieter), Berechtigungs-/Trennungskonzept.
- **Vorlage:** R12; VA-11; BL-NET-01
- **Ressourcen:** IT/ISB; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.4-S1 — [SOLL]
**Anforderung:** Das Trennungskonzept des Anbieters ist dokumentiert und an Änderungen angepasst.
- **Organisatorisch:** Trennungskonzept des Providers einholen, bewerten und bei Änderungen aktualisieren.
- **Technisch:** Abgleich des Anbieterkonzepts mit eigenen Schutzanforderungen (Isolationsmechanismen, Datenhaltung). Referenz: BL-NET-01.
- **Typische Nachweise:** Dokumentiertes Anbieter-Trennungskonzept, Bewertung/Review.
- **Vorlage:** R12; VA-11
- **Ressourcen:** ISB; gering.
- **AL-Filter:** AL2 + AL3
## Control 5.3.4-KI — Nutzung von KI-/GenAI-Diensten
### 5.3.4-KI-M1 — [MUSS]
**Anforderung:** Der Einsatz von KI-/GenAI-Diensten ist geregelt; es werden nur freigegebene Dienste genutzt.
- **Organisatorisch:** KI-Nutzungsrichtlinie mit Freigabeprozess und Positivliste zugelassener Dienste etablieren.
- **Technisch:** Nutzung nicht freigegebener KI-Dienste über Web-Proxy/CASB einschränken; Freigabeliste technisch durchsetzen. Referenz: BL-NET-02 (Web-/Dienstfreigaben).
- **Typische Nachweise:** KI-Richtlinie, Liste freigegebener Dienste, Proxy-/CASB-Regeln.
- **Vorlage:** R12; VA-11; BL-NET-02
- **Ressourcen:** ISB/IT-Betrieb; gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.4-KI-M2 — [MUSS]
**Anforderung:** Die Eingabe vertraulicher/personenbezogener Informationen in nicht freigegebene KI-Dienste ist untersagt; zulässige Datenklassen je Dienst sind definiert.
- **Organisatorisch:** Zulässige Datenklassen je freigegebenem Dienst festlegen und Verbot für nicht freigegebene Dienste kommunizieren.
- **Technisch:** DLP-Regeln zur Erkennung/Blockierung sensibler Eingaben an KI-Endpunkte. Referenz: BL-NET-02.
- **Typische Nachweise:** Datenklassen-Mapping je Dienst, DLP-Regeln, Sensibilisierungsnachweis.
- **Vorlage:** R12; VA-11
- **Ressourcen:** ISB/IT-Betrieb; ggf. DLP (Beschaffung möglich); gering–mittel.
- **AL-Filter:** AL2 + AL3
### 5.3.4-KI-M3 — [MUSS]
**Anforderung:** Bei freigegebenen KI-Diensten ist vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder weitergegeben werden.
- **Organisatorisch:** Vertrags-/AVV-Prüfung auf No-Training- und Weitergabeklauseln; nur Dienste mit passenden Zusicherungen freigeben.
- **Technisch:** Enterprise-/Business-Tarife mit deaktiviertem Training und Datenresidenz nutzen. Referenz: BL-CRY-03 (Datenhoheit).
- **Typische Nachweise:** Vertrag/AVV mit No-Training-Klausel, Konfigurationsnachweis (Training deaktiviert).
- **Vorlage:** R12; VA-11
- **Ressourcen:** Einkauf/ISB/Datenschutz; gering.
- **AL-Filter:** AL2 + AL3
### 5.3.4-KI-S1 — [SOLL]
**Anforderung:** Ergebnisse von KI-Diensten werden vor geschäftskritischer Verwendung geprüft (Human-in-the-Loop); der Einsatz wird dokumentiert und regulatorische Anforderungen (z. B. EU AI Act) berücksichtigt.
- **Organisatorisch:** Human-in-the-Loop-Vorgabe für kritische Ergebnisse, KI-Einsatzregister und Abgleich mit regulatorischen Pflichten (Risikoklassifizierung nach EU AI Act).
- **Technisch:** Kennzeichnung/Protokollierung von KI-generierten Inhalten, Freigabe-Workflows vor produktiver Nutzung. Referenz: BL-OPS-04 (Protokollierung).
- **Typische Nachweise:** KI-Einsatzregister, Prüf-/Freigabevermerke, AI-Act-Einordnung.
- **Vorlage:** R12; VA-11
- **Ressourcen:** ISB/Fachbereich/Datenschutz; gering–mittel.
- **AL-Filter:** AL2 + AL3
---
# Kapitel 6–7 — Lieferanten & Compliance/Datenschutz
## Control 6.1.1 — Sicherheit bei Auftragnehmern/Lieferanten (Risikobewertung & Verträge)
### 6.1.1-M1 — [MUSS]
**Anforderung:** Auftragnehmer und Partner werden einer Sicherheitsrisikobewertung unterzogen.
- **Organisatorisch:** Lieferantenverzeichnis führen und jeden sicherheitsrelevanten Auftragnehmer vor Beauftragung sowie regelmäßig anhand eines standardisierten Risikofragebogens (Kritikalität, verarbeitete Informationswerte, Zugriffsart) bewerten; Verantwortlichkeit im Einkauf/ISB verankern.
- **Technisch:** Bewertungen in einem GRC-/Lieferantenmanagement-Tool oder strukturiert im Ticket-/Vertragssystem erfassen, mit Wiedervorlage/Reassessment-Fristen.
- **Typische Nachweise:** Ausgefüllte Risikobewertungen je Lieferant, Lieferantenverzeichnis mit Kritikalitätseinstufung, Nachweis der Wiedervorlage.
- **Vorlage:** R13; VA-10
- **Ressourcen:** ISB/Einkauf, moderater Aufwand; GRC-/Lieferantentool optional (Beschaffung möglich).
- **AL-Filter:** AL2 + AL3
### 6.1.1-M2 — [MUSS]
**Anforderung:** Ein angemessenes Informationssicherheitsniveau wird durch vertragliche Vereinbarungen mit Auftragnehmern und Partnern sichergestellt.
- **Organisatorisch:** Standardklauseln zur Informationssicherheit (Schutzniveau, Meldepflichten, Auditrechte, Unterauftragnehmer) in Verträge/AGB aufnehmen; Freigabe durch Recht/ISB vor Vertragsschluss.
- **Technisch:** Vertragsvorlagen mit IS-Klauselkatalog im Vertragsmanagement hinterlegen; Versionsverwaltung der Klauseln.
- **Typische Nachweise:** Unterzeichnete Verträge mit IS-Klauseln, Klauselkatalog/Vertragsmuster, Freigabevermerk.
- **Vorlage:** R13; VA-10
- **Ressourcen:** Recht/Einkauf/ISB, initial erhöht (Klauselerstellung), danach gering.
- **AL-Filter:** AL2 + AL3
### 6.1.1-M3 — [MUSS]
**Anforderung:** Sofern zutreffend, werden vertragliche Vereinbarungen mit Auftraggebern/Kunden an Auftragnehmer und Partner weitergegeben.
- **Organisatorisch:** Kundenspezifische Sicherheitsanforderungen (Flow-down) identifizieren und verpflichtend in die Unterverträge übernehmen; Zuordnung Kundenanforderung → Lieferantenvertrag dokumentieren.
- **Technisch:** Anforderungsmatrix/Mapping-Tabelle im Vertrags- oder Anforderungsmanagement pflegen.
- **Typische Nachweise:** Flow-down-Klauseln in Unterverträgen, Mapping Kunden-/Lieferantenanforderungen.
- **Vorlage:** R13
- **Ressourcen:** Recht/Einkauf, geringer bis moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.1-S1 — [SOLL]
**Anforderung:** Auftragnehmer und Partner sind vertraglich verpflichtet, Anforderungen an ein angemessenes Informationssicherheitsniveau an ihre Unterauftragnehmer weiterzugeben.
- **Organisatorisch:** Verpflichtung zur Weitergabe der IS-Anforderungen an Unterauftragnehmer als Standardklausel festlegen; Genehmigungspflicht für Unterbeauftragung vereinbaren.
- **Technisch:** Klausel im Vertragsmuster hinterlegen; Register der zugelassenen Unterauftragnehmer.
- **Typische Nachweise:** Vertragsklausel zur Weitergabe, Liste/Freigaben von Unterauftragnehmern.
- **Vorlage:** R13; VA-10
- **Ressourcen:** Recht/Einkauf, geringer Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.1-S2 — [SOLL]
**Anforderung:** Leistungsberichte und Dokumente von Auftragnehmern und Partnern werden geprüft.
- **Organisatorisch:** Regelmäßige Auswertung von Leistungs-/Service-Berichten (SLA-Erfüllung, Sicherheitsnachweise) durch die verantwortliche Fachstelle; Abweichungen nachverfolgen.
- **Technisch:** Berichtseingang und Prüfung im Lieferantenmanagement-/Ticketsystem dokumentieren, mit Fristen.
- **Typische Nachweise:** Geprüfte Leistungsberichte, Prüfvermerke, Maßnahmen-/Eskalationsnachweise.
- **Vorlage:** R13
- **Ressourcen:** Fachbereich/Einkauf, laufender geringer Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.1-H1 — [HOCH]
**Anforderung:** Es wird nachgewiesen, dass das Informationssicherheitsniveau des Lieferanten dem Schutzbedarf angemessen ist (z. B. geprüfter Fragebogen/Selbstauskunft, Attestierung, Zertifikat, Lieferantenaudit).
- **Organisatorisch:** Für Lieferanten mit hohem Schutzbedarf verbindlichen Nachweistyp festlegen (Selbstauskunft mit Plausibilitätsprüfung, ISO-27001-/TISAX-Nachweis oder Audit) und einholen/bewerten.
- **Technisch:** Nachweise (Zertifikate, ausgefüllte Fragebögen) revisionssicher im GRC-/Lieferantentool ablegen, mit Gültigkeitsüberwachung.
- **Typische Nachweise:** Geprüfte Selbstauskunft, Zertifikat/Attestierung, Auditbericht, Bewertungsvermerk.
- **Vorlage:** R13
- **Ressourcen:** ISB, erhöhter Aufwand; ggf. Auditkosten (Budget).
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 6.1.1-H2 — [HOCH]
**Anforderung:** Der Grad der Erfüllung geforderter Nachweise durch den Lieferanten wird dokumentiert, regelmäßig und bei Änderungen überprüft und überwacht.
- **Organisatorisch:** Erfüllungsgrad je geforderten Nachweis dokumentieren und in einem Reassessment-Zyklus sowie anlassbezogen (Vertrags-/Leistungsänderung) neu bewerten.
- **Technisch:** Statusübersicht (offen/erfüllt/abgelaufen) im GRC-Tool mit automatischen Erinnerungen.
- **Typische Nachweise:** Nachweis-Statusübersicht, Reassessment-Protokolle, Änderungshistorie.
- **Vorlage:** R13
- **Ressourcen:** ISB, laufender moderater Aufwand.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 6.1.1-H3 — [HOCH]
**Anforderung:** Die Einhaltung vertraglicher Vereinbarungen durch den Lieferanten wird geprüft, dokumentiert, regelmäßig und bei Änderungen überprüft und überwacht.
- **Organisatorisch:** Vertragskonformität (IS-Klauseln, SLAs, Meldepflichten) regelmäßig prüfen; Feststellungen mit Maßnahmen und Eskalation verfolgen.
- **Technisch:** Prüf- und Maßnahmenverfolgung im Lieferanten-/GRC-Tool; Verknüpfung Vertrag ↔ Prüfergebnis.
- **Typische Nachweise:** Prüfprotokolle Vertragskonformität, Maßnahmenliste, Eskalationsnachweise.
- **Vorlage:** R13
- **Ressourcen:** ISB/Einkauf, laufender moderater Aufwand.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 6.1.1-V1 — [SEHR HOCH]
**Anforderung:** Das angemessene Informationssicherheitsniveau sollte durch ein Drittparteien-Audit (angemessenes TISAX-Label o. Ä.) oder ein angemessenes Lieferantenaudit nachgewiesen werden. Ohne Audit muss die Leitung eine risikobasierte Entscheidung zur Fortführung treffen; ein Nachweis dieser Entscheidung existiert.
- **Organisatorisch:** Für Lieferanten mit sehr hohem Schutzbedarf ein passendes TISAX-Label bzw. Lieferantenaudit einfordern; liegt keines vor, dokumentierte, risikobasierte Leitungsentscheidung (Risk Acceptance) herbeiführen.
- **Technisch:** Label-/Auditnachweise und Leitungsentscheid revisionssicher im GRC-Tool ablegen, mit Gültigkeits- und Wiedervorlagesteuerung.
- **Typische Nachweise:** TISAX-Label/Auditbericht, dokumentierte Leitungsentscheidung mit Risikobegründung.
- **Vorlage:** R13
- **Ressourcen:** Leitung/ISB, hoher Aufwand; Auditkosten (Budget).
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
### 6.1.1-V2 — [SEHR HOCH]
**Anforderung:** Vertragliche Verpflichtungen gegenüber Kunden zur Transparenz von Lieferkettenrisiken werden erfüllt.
- **Organisatorisch:** Kundenanforderungen zur Lieferketten-Transparenz identifizieren und ein Verfahren zur Offenlegung relevanter Lieferkettenrisiken (inkl. Unterauftragnehmer) etablieren.
- **Technisch:** Lieferketten-/Risikoregister mit Zuordnung zu Kundenverträgen; Reporting-Auszüge für Kunden generierbar.
- **Typische Nachweise:** Lieferkettenübersicht, an Kunden erbrachte Transparenznachweise, Vertragsbezug.
- **Vorlage:** R13
- **Ressourcen:** ISB/Einkauf, erhöhter Aufwand.
- **AL-Filter:** AL3 (sehr hoher Schutzbedarf)
## Control 6.1.2 — Vertraulichkeitsvereinbarungen (NDA) bei Informationsweitergabe
### 6.1.2-M1 — [MUSS]
**Anforderung:** Die Vertraulichkeitsanforderungen sind bestimmt und erfüllt.
- **Organisatorisch:** Anlässe und Umfang von Vertraulichkeitsverpflichtungen (welche Informationsklassen, welche Empfänger) bestimmen und in einer Regelung festhalten; Umsetzung sicherstellen.
- **Technisch:** Verknüpfung mit dem Klassifizierungsschema; NDA-Pflicht als Attribut in Vertrags-/Partnerstammdaten.
- **Typische Nachweise:** Dokumentierte Vertraulichkeitsanforderungen, Bezug zum Klassifizierungsschema.
- **Vorlage:** R13; VA-10
- **Ressourcen:** ISB/Recht, geringer bis moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.2-M2 — [MUSS]
**Anforderung:** Anforderungen und Verfahren zur Anwendung von Vertraulichkeitsvereinbarungen sind allen Personen bekannt, die schutzbedürftige Informationen weitergeben.
- **Organisatorisch:** Verfahren zur NDA-Anwendung kommunizieren (Onboarding, Richtlinie, Schulung); Ansprechpartner für den NDA-Abschluss benennen.
- **Technisch:** Richtlinie und NDA-Vorlagen im Intranet/Dokumentenmanagement zugänglich machen.
- **Typische Nachweise:** Veröffentlichte Richtlinie/Arbeitsanweisung, Schulungs-/Kenntnisnahmenachweise.
- **Vorlage:** R13
- **Ressourcen:** ISB, geringer Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.2-M3 — [MUSS]
**Anforderung:** Gültige Vertraulichkeitsvereinbarungen werden vor der Weitergabe schutzbedürftiger Informationen abgeschlossen.
- **Organisatorisch:** Verbindliche Regel „kein Informationsaustausch ohne gültiges NDA"; NDA-Abschluss als Voraussetzung im Freigabe-/Beschaffungsprozess verankern.
- **Technisch:** NDA-Status als Gate im Workflow (Vertrags-/Ticketsystem) prüfen, bevor Zugriff/Weitergabe erfolgt.
- **Typische Nachweise:** Abgeschlossene, gültige NDAs vor Austauschbeginn, Freigabe-Workflow mit NDA-Prüfung.
- **Vorlage:** R13
- **Ressourcen:** Recht/Fachbereich, laufender geringer Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.2-M4 — [MUSS]
**Anforderung:** Die Anforderungen und Verfahren zur Nutzung von Vertraulichkeitsvereinbarungen und zum Umgang mit schutzbedürftigen Informationen werden regelmäßig überprüft.
- **Organisatorisch:** NDA-Verfahren und -Vorlagen in einem festen Turnus sowie bei Rechtsänderungen überprüfen und aktualisieren; Review dokumentieren.
- **Technisch:** Review-Termine/Versionsstände im Dokumentenmanagement mit Wiedervorlage steuern.
- **Typische Nachweise:** Review-Protokolle, Versionshistorie der NDA-Vorlagen/-Richtlinie.
- **Vorlage:** R13
- **Ressourcen:** ISB/Recht, geringer wiederkehrender Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.2-S1 — [SOLL]
**Anforderung:** Vorlagen für Vertraulichkeitsvereinbarungen sind vorhanden und auf rechtliche Anwendbarkeit geprüft.
- **Organisatorisch:** Standard-NDA-Vorlagen (ein-/beidseitig) bereitstellen und durch die Rechtsfunktion auf Anwendbarkeit (Jurisdiktion, Durchsetzbarkeit) prüfen lassen.
- **Technisch:** Freigegebene Vorlagen zentral im Dokumentenmanagement, mit Kennzeichnung der geprüften Version.
- **Typische Nachweise:** Freigegebene NDA-Vorlagen, rechtlicher Prüfvermerk.
- **Vorlage:** R13; VA-10
- **Ressourcen:** Recht, initial moderat.
- **AL-Filter:** AL2 + AL3
### 6.1.2-S2 — [SOLL]
**Anforderung:** Vertraulichkeitsvereinbarungen umfassen beteiligte Personen/Organisationen, Art der Informationen, Gegenstand, Gültigkeitsdauer und Verantwortlichkeiten der verpflichteten Partei.
- **Organisatorisch:** Mindestinhalte für NDAs verbindlich festlegen und in die Vorlage aufnehmen (Parteien, Informationsarten, Zweck, Laufzeit, Pflichten).
- **Technisch:** Vorlagen-Checkliste/Formularfelder zur Vollständigkeitsprüfung.
- **Typische Nachweise:** NDA-Vorlage mit Pflichtinhalten, Beispielverträge.
- **Vorlage:** R13
- **Ressourcen:** Recht/ISB, geringer Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.2-S3 — [SOLL]
**Anforderung:** Vertraulichkeitsvereinbarungen enthalten Regelungen zum Umgang mit schutzbedürftigen Informationen über die Vertragsbeziehung hinaus.
- **Organisatorisch:** Nachvertragliche Pflichten (Rückgabe/Löschung, Fortdauer der Geheimhaltung) verbindlich in NDAs regeln.
- **Technisch:** Entsprechende Standardklausel in der Vorlage hinterlegen.
- **Typische Nachweise:** NDA-Klausel zu nachvertraglichen Pflichten.
- **Vorlage:** R13
- **Ressourcen:** Recht, geringer Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.2-S4 — [SOLL]
**Anforderung:** Möglichkeiten zum Nachweis der Einhaltung (z. B. Prüfung durch unabhängige Dritte oder Auditrechte) sind definiert.
- **Organisatorisch:** Prüf-/Auditrechte oder Nachweispflichten zur NDA-Einhaltung in der Vereinbarung verankern.
- **Technisch:** Klausel in Vorlage; Nachverfolgung ausgeübter Prüfrechte im Vertragsmanagement.
- **Typische Nachweise:** Auditrechtsklausel, ggf. durchgeführte Prüfungen/Nachweise.
- **Vorlage:** R13
- **Ressourcen:** Recht/ISB, geringer Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.2-S5 — [SOLL]
**Anforderung:** Ein Prozess zur Überwachung der Gültigkeitsdauer temporärer Vertraulichkeitsvereinbarungen und zur rechtzeitigen Verlängerung ist definiert und umgesetzt.
- **Organisatorisch:** Fristenmanagement für befristete NDAs mit definierter Verantwortlichkeit und Verlängerungs-/Nachfassprozess etablieren.
- **Technisch:** Ablaufüberwachung mit automatischen Erinnerungen im Vertragsmanagement/Kalender.
- **Typische Nachweise:** Fristenübersicht mit Ablaufdaten, Erinnerungs-/Verlängerungsnachweise.
- **Vorlage:** R13
- **Ressourcen:** Einkauf/Recht, geringer laufender Aufwand.
- **AL-Filter:** AL2 + AL3
## Control 6.1.3 — Sicherheit externer IT-Dienste & geteilte Verantwortlichkeiten
### 6.1.3-M1 — [MUSS]
**Anforderung:** Die betroffenen IT-Dienste sind identifiziert.
- **Organisatorisch:** Alle genutzten externen IT-Dienste (Cloud/SaaS/Managed Services) erfassen und einem Verantwortlichen zuordnen; Bezug zu verarbeiteten Informationswerten herstellen.
- **Technisch:** Dienstinventar im Asset-/CMDB- oder GRC-Tool führen, verknüpft mit dem Asset-Register.
- **Typische Nachweise:** Inventar externer IT-Dienste, Zuordnung zu Assets/Verantwortlichen.
- **Vorlage:** R13; VA-10
- **Ressourcen:** IT/ISB, moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.3-M2 — [MUSS]
**Anforderung:** Die für den IT-Dienst relevanten Sicherheitsanforderungen sind bestimmt.
- **Organisatorisch:** Je Dienst die Sicherheitsanforderungen aus Schutzbedarf und Klassifizierung ableiten und dokumentieren (Vertraulichkeit, Integrität, Verfügbarkeit, Standort/Rechtsraum).
- **Technisch:** Anforderungskatalog je Dienst hinterlegen; Abgleich mit Konfigurations-Baselines des Dienstes.
- **Typische Nachweise:** Dokumentierte Sicherheitsanforderungen je Dienst, Schutzbedarfsableitung.
- **Vorlage:** R13
- **Ressourcen:** ISB/Fachbereich, moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.3-M3 — [MUSS]
**Anforderung:** Die für die Umsetzung der Anforderung verantwortliche Organisation ist definiert und sich ihrer Verantwortung bewusst.
- **Organisatorisch:** Für jede Anforderung festlegen, ob Anbieter oder eigene Organisation zuständig ist, und die Zuständigkeit gegenüber der verantwortlichen Stelle bestätigen.
- **Technisch:** Verantwortungszuordnung im Dienstinventar/Responsibility-Matrix dokumentieren.
- **Typische Nachweise:** Verantwortlichkeitszuordnung je Dienst/Anforderung, Bestätigung der zuständigen Stelle.
- **Vorlage:** R13
- **Ressourcen:** ISB, geringer Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.3-M4 — [MUSS]
**Anforderung:** Mechanismen für geteilte Verantwortlichkeiten sind spezifiziert und umgesetzt.
- **Organisatorisch:** Shared-Responsibility-Modell je Dienst festlegen (wer verantwortet welche Kontrolle) und die eigenen Pflichtanteile umsetzen.
- **Technisch:** Verantwortungsmatrix (Anbieter/Kunde) je Kontrollbereich; kundenseitige Konfigurationen (z. B. Zugriffsschutz, Verschlüsselung) gemäß Baseline umsetzen (BL-IAM-01 Passwort/Authentifizierung).
- **Typische Nachweise:** Responsibility-Matrix, umgesetzte kundenseitige Kontrollen, Konfigurationsnachweise.
- **Vorlage:** R13; BL-IAM-01
- **Ressourcen:** IT/ISB, moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.3-M5 — [MUSS]
**Anforderung:** Die verantwortliche Organisation erfüllt ihre jeweiligen Verantwortlichkeiten.
- **Organisatorisch:** Erfüllung der eigenen und (per Nachweis) der anbieterseitigen Pflichten sicherstellen und regelmäßig kontrollieren.
- **Technisch:** Kontrollnachweise (eigene Konfigurationen, Anbieter-Reports/Zertifikate) sammeln und auswerten.
- **Typische Nachweise:** Nachweise erfüllter Pflichten (eigene und Anbieter), Kontrollberichte.
- **Vorlage:** R13
- **Ressourcen:** IT/ISB, laufender Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.3-S1 — [SOLL]
**Anforderung:** Bei IT-Diensten ist die Konfiguration auf Basis der notwendigen Sicherheitsanforderungen konzipiert, umgesetzt und dokumentiert.
- **Organisatorisch:** Sichere Sollkonfiguration je Dienst festlegen, freigeben und dokumentieren; Abweichungen begründen.
- **Technisch:** Konfigurations-Baseline/Hardening-Vorgaben anwenden; Ist-Konfiguration dokumentieren und gegen Soll prüfen (BL-OPS-Härtung).
- **Typische Nachweise:** Konfigurationskonzept/-dokumentation je Dienst, Soll-/Ist-Abgleich.
- **Vorlage:** R13; BL-OPS-01
- **Ressourcen:** IT, moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 6.1.3-S2 — [SOLL]
**Anforderung:** Das verantwortliche Personal ist angemessen geschult.
- **Organisatorisch:** Für die Dienstverwaltung zuständiges Personal gezielt zu Konfiguration/Sicherheit der jeweiligen Dienste schulen.
- **Technisch:** Schulungs-/Zertifizierungsnachweise im Schulungsmanagement erfassen.
- **Typische Nachweise:** Schulungsnachweise, Qualifikationsnachweise des Personals.
- **Vorlage:** R13; VA-12
- **Ressourcen:** Personal/Budget für Schulungen.
- **AL-Filter:** AL2 + AL3
### 6.1.3-H1 — [HOCH]
**Anforderung:** Eine Liste der betroffenen IT-Dienste und der jeweils verantwortlichen IT-Dienstleister existiert.
- **Organisatorisch:** Vollständige, gepflegte Liste der Dienste inkl. verantwortlichem Dienstleister und Kontaktinformationen führen.
- **Technisch:** Dienst-/Dienstleisterregister im CMDB-/GRC-Tool mit Aktualisierungsroutine.
- **Typische Nachweise:** Aktuelle Dienst-/Dienstleisterliste, Pflegehistorie.
- **Vorlage:** R13
- **Ressourcen:** IT/ISB, geringer laufender Aufwand.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 6.1.3-H2 — [HOCH]
**Anforderung:** Die Anwendbarkeit der ISA-Controls wurde bewertet und dokumentiert.
- **Organisatorisch:** Je Dienst die anwendbaren ISA-Controls bestimmen und die Bewertung dokumentieren (Applicability-Statement je Dienst).
- **Technisch:** Control-Mapping je Dienst im GRC-Tool hinterlegen.
- **Typische Nachweise:** Dokumentierte ISA-Anwendbarkeitsbewertung je Dienst.
- **Vorlage:** R13
- **Ressourcen:** ISB, moderater Aufwand.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 6.1.3-H3 — [HOCH]
**Anforderung:** Die Dienstkonfiguration ist in die regelmäßigen Sicherheitsbewertungen einbezogen.
- **Organisatorisch:** Dienstkonfigurationen in den Turnus der internen Sicherheitsüberprüfungen/Audits aufnehmen.
- **Technisch:** Wiederkehrende Konfigurations-Reviews/Compliance-Scans der Dienste; Ergebnisse dokumentieren (BL-OPS-Monitoring).
- **Typische Nachweise:** Prüfpläne mit Diensten, Review-/Scan-Ergebnisse.
- **Vorlage:** R13; VA-15
- **Ressourcen:** IT/ISB, laufender Aufwand.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 6.1.3-H4 — [HOCH]
**Anforderung:** Es wird nachgewiesen, dass die IT-Dienstleister ihre Verantwortung erfüllen.
- **Organisatorisch:** Von Dienstleistern regelmäßig Nachweise (Zertifikate, SOC-/Prüfberichte, SLA-Reports) einfordern und bewerten.
- **Technisch:** Nachweiseingang und -bewertung im Lieferanten-/GRC-Tool mit Gültigkeitsüberwachung.
- **Typische Nachweise:** Anbieterzertifikate/Prüfberichte, Bewertungsvermerke.
- **Vorlage:** R13
- **Ressourcen:** ISB, laufender moderater Aufwand.
- **AL-Filter:** AL3 (hoher Schutzbedarf)
### 6.1.3-H5 — [HOCH]
**Anforderung:** Die Integration in lokale Schutzmaßnahmen (z. B. sichere Authentifizierungsmechanismen) ist etabliert und dokumentiert.
- **Organisatorisch:** Anbindung der Dienste an die eigenen Schutzmaßnahmen (zentrale Identität, Zugriffskontrolle, Protokollierung) verbindlich festlegen und dokumentieren.
- **Technisch:** SSO/Federation, MFA und Log-Anbindung an SIEM konfigurieren (BL-IAM-01 Authentifizierung, BL-IAM-02 MFA).
- **Typische Nachweise:** Integrationsdokumentation, SSO-/MFA-Konfiguration, Log-Anbindungsnachweis.
- **Vorlage:** R13; BL-IAM-01; BL-IAM-02
- **Ressourcen:** IT, erhöhter Aufwand; ggf. Tooling (Beschaffung).
- **AL-Filter:** AL3 (hoher Schutzbedarf)
## Control 7.1.1 — Einhaltung rechtlicher, regulatorischer & vertraglicher Vorgaben
### 7.1.1-M1 — [MUSS]
**Anforderung:** Rechtliche, regulatorische und vertragliche Vorgaben mit Relevanz für die Informationssicherheit werden regelmäßig bestimmt.
- **Organisatorisch:** Ein Compliance-/Rechtskataster mit IS-relevanten Vorgaben (Gesetze, Normen, Verträge) führen und regelmäßig sowie anlassbezogen aktualisieren; Verantwortlichkeit benennen.
- **Technisch:** Anforderungsregister/GRC-Tool mit Quellen, Fristen und Verantwortlichen; Wiedervorlage für Updates.
- **Typische Nachweise:** Aktuelles Compliance-Register, Aktualisierungshistorie, Verantwortlichkeitszuordnung.
- **Vorlage:** R14; VA-18
- **Ressourcen:** ISB/Recht, moderater laufender Aufwand.
- **AL-Filter:** AL2 + AL3
### 7.1.1-M2 — [MUSS]
**Anforderung:** Richtlinien zur Einhaltung der Vorgaben sind definiert, umgesetzt und den verantwortlichen Personen kommuniziert.
- **Organisatorisch:** Zu den identifizierten Vorgaben konkrete Umsetzungsrichtlinien/-vorgaben ableiten, umsetzen und den Verantwortlichen bekannt machen.
- **Technisch:** Richtlinien im Dokumentenmanagement/Intranet bereitstellen; Mapping Vorgabe → Richtlinie → Maßnahme.
- **Typische Nachweise:** Veröffentlichte Compliance-Richtlinien, Mapping Vorgabe/Maßnahme, Kommunikations-/Kenntnisnahmenachweise.
- **Vorlage:** R14; VA-18
- **Ressourcen:** ISB/Recht, moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 7.1.1-S1 — [SOLL]
**Anforderung:** Die Integrität von Aufzeichnungen entsprechend rechtlichen, regulatorischen und vertraglichen Vorgaben sowie Geschäftsanforderungen wird berücksichtigt.
- **Organisatorisch:** Aufbewahrungs- und Integritätsanforderungen für nachweispflichtige Aufzeichnungen bestimmen und in Handhabungsvorgaben festlegen.
- **Technisch:** Manipulationssichere/revisionssichere Ablage (WORM, Zugriffsschutz, Protokollierung), ggf. mit definierter Aufbewahrungsdauer (BL-OPS-05 Backup/Aufbewahrung).
- **Typische Nachweise:** Aufbewahrungs-/Integritätsvorgaben, Nachweis revisionssicherer Speicherung.
- **Vorlage:** R14; BL-OPS-05
- **Ressourcen:** IT/ISB, moderater Aufwand; ggf. Archivierungslösung (Beschaffung).
- **AL-Filter:** AL2 + AL3
## Control 7.1.2 — Schutz personenbezogener Daten (Datenschutz)
### 7.1.2-M1 — [MUSS]
**Anforderung:** Rechtliche und vertragliche Informationssicherheitsanforderungen an Verfahren und Prozesse bei der Verarbeitung personenbezogener Daten sind bestimmt.
- **Organisatorisch:** Verarbeitungen personenbezogener Daten erfassen (Verzeichnis von Verarbeitungstätigkeiten) und die daraus folgenden rechtlichen/vertraglichen IS-Anforderungen (z. B. DSGVO) bestimmen; DSB einbinden.
- **Technisch:** VVT und Anforderungszuordnung im GRC-/Datenschutz-Tool pflegen.
- **Typische Nachweise:** Verzeichnis der Verarbeitungstätigkeiten, dokumentierte Datenschutz-/IS-Anforderungen.
- **Vorlage:** R14; VA-18
- **Ressourcen:** DSB/ISB, moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 7.1.2-M2 — [MUSS]
**Anforderung:** Regelungen zur Einhaltung rechtlicher und vertraglicher Anforderungen an den Schutz personenbezogener Daten sind definiert und den beteiligten Personen bekannt.
- **Organisatorisch:** Datenschutzrichtlinie/-vorgaben (inkl. Betroffenenrechte, Meldepflichten, AVV) definieren und den beteiligten Personen kommunizieren/schulen.
- **Technisch:** Richtlinien und AVV-Vorlagen im Dokumentenmanagement bereitstellen; technische Schutzmaßnahmen (Zugriffsschutz, Verschlüsselung) gemäß Baseline.
- **Typische Nachweise:** Datenschutzrichtlinie, Schulungs-/Kenntnisnahmenachweise, AVV-Vorlagen.
- **Vorlage:** R14; VA-18; BL-IAM-01
- **Ressourcen:** DSB/ISB, moderater Aufwand.
- **AL-Filter:** AL2 + AL3
### 7.1.2-M3 — [MUSS]
**Anforderung:** Prozesse und Verfahren zum Schutz personenbezogener Daten sind im Informationssicherheits-Managementsystem berücksichtigt.
- **Organisatorisch:** Datenschutzprozesse (z. B. Betroffenenanfragen, Datenpannen, DSFA) mit dem ISMS verzahnen (gemeinsame Risiko-, Vorfall- und Überprüfungsprozesse).
- **Technisch:** Verknüpfung von Datenschutz- und ISMS-Prozessen in GRC-/Incident-Tools (z. B. gemeinsamer Meldeworkflow für Datenpannen).
- **Typische Nachweise:** Integrierte Prozessdokumentation, Verweise Datenschutz ↔ ISMS (Risiko/Incident), DSFA-Beispiele.
- **Vorlage:** R14; VA-18; VA-09
- **Ressourcen:** DSB/ISB, moderater Aufwand.
- **AL-Filter:** AL2 + AL3
---
# Prototypenschutz (8.x) & Datenschutz (9.x)
# Prototypenschutz (8.x)
## Control 8.1.1 — Sicherheitskonzept physische/umgebungsbezogene Sicherheit
### 8.1.1-M1 — [MUSS]
**Anforderung:** Sicherheitskonzept mit Außenhaut, Sicht-/Einblickschutz, Zutrittsschutz/-kontrolle, Einbruch-Überwachung, dokumentiertem Besuchermanagement und Mandantentrennung.
- **Organisatorisch:** Ein objektbezogenes Sicherheitskonzept je Liegenschaft/Sicherheitsbereich erstellen, das alle sechs Aspekte behandelt, Verantwortlichen (Betreiber/Objektsicherheit) benennen und durch die Leitung freigeben lassen; regelmäßige Review-Zyklen (mind. jährlich) festlegen.
- **Technisch:** Bestandteile technisch belegen (Schließplan, EMA/Videokonzept, Zonenplan mit Sicherheitsbereichen); Schutzbereiche in einem Liegenschaftsplan/Zonenmodell dokumentieren.
- **Typische Nachweise:** Freigegebenes Sicherheitskonzept, Zonen-/Liegenschaftsplan, Review-Protokoll, Zuständigkeitsmatrix.
- **Vorlage:** Richtlinie Prototypenschutz (P01, neu anzulegen); R07 physische Sicherheit; VA-17 Zutritt/Besucher.
- **Ressourcen:** Objektsicherheit/Werkschutz; Erstaufwand für Konzepterstellung (ggf. externe Beratung), danach jährliche Pflege.
- **AL-Filter:** AL2 | AL3
### 8.1.1-S1 — [SOLL]
**Anforderung:** Perimetersicherung.
- **Organisatorisch:** Perimeterschutz als eigenen Baustein im Sicherheitskonzept beschreiben (Geltungsbereich Grundstücksgrenze).
- **Technisch:** Umzäunung/Mauer, Toranlagen, ggf. Außenhautdetektion und Beleuchtung; Zufahrtskontrolle festlegen.
- **Typische Nachweise:** Perimeterkonzept, Fotodokumentation, Wartungsnachweise Zaun/Tore.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Investitionsbedarf für bauliche Maßnahmen (Beschaffung/Bau) — führt zu Umsetzungsaufgabe.
- **AL-Filter:** AL2 | AL3
## Control 8.1.2 — Perimeterschutz gegen unberechtigten Zutritt
### 8.1.2-M1 — [MUSS]
**Anforderung:** Der unberechtigte Zutritt zu Liegenschaften ist nicht möglich.
- **Organisatorisch:** Zutrittspunkte inventarisieren, Zufahrts-/Zugangsregelung definieren, Verantwortlichkeit für Perimeter festlegen.
- **Technisch:** Durchgängige Umschließung (Zaun/Mauer/Gebäudefront), gesicherte Tore/Schranken, ggf. Detektion; keine ungesicherten Nebenzugänge.
- **Typische Nachweise:** Perimeterplan, Begehungsprotokoll, Prüfung offener Zugänge.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Bauliche Maßnahmen (Beschaffung/Bau), Werkschutz.
- **AL-Filter:** AL2 | AL3
### 8.1.2-S1 — [SOLL]
**Anforderung:** Geeignete künstliche, technische und natürliche Barrieren.
- **Organisatorisch:** Barrierenkonzept mit Kombination aus künstlichen (Zaun/Mauer), technischen (Detektion) und natürlichen (Bewuchs) Barrieren dokumentieren.
- **Technisch:** Zaunsysteme, Detektionstechnik, Geländegestaltung/Bewuchs so anordnen, dass Überwindung erschwert und detektiert wird.
- **Typische Nachweise:** Barrierenkonzept, Lageplan, Fotodokumentation.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Investition bauliche/gärtnerische Maßnahmen.
- **AL-Filter:** AL2 | AL3
## Control 8.1.3 — Außenhaut Gebäude/Sicherheitsbereiche
### 8.1.3-M1 — [MUSS]
**Anforderung:** Der unberechtigte Zutritt in Gebäude/Sicherheitsbereiche ist nicht möglich.
- **Organisatorisch:** Sicherheitsbereiche definieren und abgrenzen; Anforderungen an Außenhaut (Wände, Türen, Fenster, Dach) festlegen.
- **Technisch:** Einbruchhemmende Ausführung der Außenhautkomponenten; keine mit handelsüblichem Werkzeug zu öffnenden Elemente.
- **Typische Nachweise:** Bauunterlagen/Zertifikate der Bauteile, Begehungsprotokoll, Mängelliste.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Bauliche Ertüchtigung (Beschaffung/Bau).
- **AL-Filter:** AL2 | AL3
### 8.1.3-S1 — [SOLL]
**Anforderung:** Massive Bauweise (Mauerwerk, Beton, Stahl-/Spannbeton).
- **Organisatorisch:** Bei Neubau/Anmietung massive Bauweise als Anforderung berücksichtigen.
- **Technisch:** Massive Wandkonstruktionen; bei Leichtbau ergänzende Verstärkungen/Detektion vorsehen.
- **Typische Nachweise:** Baubeschreibung, Statik-/Bauunterlagen, Fotodokumentation.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Baulicher Investitionsbedarf.
- **AL-Filter:** AL2 | AL3
### 8.1.3-S2 — [SOLL]
**Anforderung:** Fenster und Türen in der Außenhaut in RC2 oder höher.
- **Organisatorisch:** RC-Klasse als Beschaffungsvorgabe für Fenster/Türen setzen; Bestand bewerten.
- **Technisch:** Einbruchhemmende Fenster/Türen nach DIN EN 1627 (RC2+), inkl. Verglasung und Beschlägen.
- **Typische Nachweise:** RC-Zertifikate/Herstellernachweise, Einbaudokumentation.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Beschaffung einbruchhemmender Elemente.
- **AL-Filter:** AL2 | AL3
## Control 8.1.4 — Sicht- und Einblickschutz
### 8.1.4-M1 — [MUSS]
**Anforderung:** Unberechtigter Einblick auf Neuentwicklungen mit hohem/sehr hohem Schutzbedarf ist nicht möglich.
- **Organisatorisch:** Sicht-/Einblickschutz für Sicherheitsbereiche festlegen; Verhaltensregeln (Türen/Tore geschlossen halten) definieren.
- **Technisch:** Sichtschutz an Fenstern/Glasflächen, blickdichte Tore/Vorhänge, bauliche Sichtbarrieren; Positionierung schutzbedürftiger Objekte außerhalb einsehbarer Zonen.
- **Typische Nachweise:** Einblickschutzkonzept, Begehungsprotokoll (Einsehbarkeit), Fotodokumentation.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Beschaffung Sichtschutzmaßnahmen.
- **AL-Filter:** AL2 | AL3
### 8.1.4-S1 — [SOLL]
**Anforderung:** Schutz vor Einblick durch relevante Glasflächen.
- **Organisatorisch:** Relevante Glasflächen identifizieren und Sichtschutzmaßnahme je Fläche festlegen.
- **Technisch:** Folierung/Milchglas, Jalousien/Rollos, blickdichte Verglasung.
- **Typische Nachweise:** Liste Glasflächen mit Maßnahme, Fotodokumentation.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Beschaffung/Installation Sichtschutz.
- **AL-Filter:** AL2 | AL3
### 8.1.4-S2 — [SOLL]
**Anforderung:** Einsicht in Sicherheitsbereiche durch offene Türen/Tore/Fenster wird verhindert.
- **Organisatorisch:** Verhaltensregel "Tore/Türen geschlossen" verankern, Kontrollen durchführen.
- **Technisch:** Selbstschließende Tore, Schleusen/Sichtschutzvorhänge an Zufahrten, Anordnung so, dass keine direkte Sichtachse besteht.
- **Typische Nachweise:** Verhaltensregeln, Begehungsprotokoll, Fotodokumentation.
- **Vorlage:** P01; R07 physische Sicherheit; VA-17 Zutritt/Besucher.
- **Ressourcen:** Organisatorisch gering; ggf. Nachrüstung Torautomatik.
- **AL-Filter:** AL2 | AL3
### 8.1.4-H1 — [HOCH]
**Anforderung:** Räumliche Situation auch geeignet, schutzbedürftig klassifizierte Fahrzeuge vor Einblick zu schützen.
- **Organisatorisch:** Für Fahrzeug-Schutzbedarf erweiterte Einblickschutzanforderungen festlegen (größere Objekte, Rangierflächen).
- **Technisch:** Geschlossene Hallen/Boxen, blickdichte Umhausung, Sichtschutz auch bei Rangier-/Zufahrtswegen.
- **Typische Nachweise:** Einblickschutzkonzept Fahrzeuge, Fotodokumentation, Begehung.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Bauliche Maßnahmen bei hohem Schutzbedarf.
- **AL-Filter:** AL3 (hoher/sehr hoher Schutzbedarf)
## Control 8.1.5 — Zugangskontrolle Sicherheitsbereiche
### 8.1.5-M1 — [MUSS]
**Anforderung:** Mindestens eine von drei Maßnahmen: mechanische Schlösser mit dokumentierter Schlüsselvergabe, elektronische Zugangssysteme mit dokumentierter Berechtigungsvergabe oder Personen-Zutrittskontrolle inkl. Dokumentation.
- **Organisatorisch:** Zutrittskontrollverfahren mit dokumentierter Vergabe/Entzug festlegen; Berechtigungen nach Need-to-know.
- **Technisch:** Elektronisches Zutrittskontrollsystem (Ausweis/PIN) mit Protokollierung oder Schließanlage mit Schließplan; alternativ Personenkontrolle mit Zutrittsbuch.
- **Typische Nachweise:** Schließplan/Berechtigungsliste, Zutrittsprotokolle, Vergabe-/Entzugsnachweise.
- **Vorlage:** P01; VA-17 Zutritt/Besucher; R07 physische Sicherheit.
- **Ressourcen:** ZKS-Beschaffung/-Betrieb oder Schließanlage; Werkschutz.
- **AL-Filter:** AL2 | AL3
### 8.1.5-H1 — [HOCH]
**Anforderung:** Räumliche Situation auch geeignet, schutzbedürftig klassifizierte Fahrzeuge vor unberechtigtem Zugriff zu schützen.
- **Organisatorisch:** Zutrittsregelung auf Fahrzeug-Abstellbereiche ausdehnen, verschärfte Berechtigung.
- **Technisch:** Separat gesicherte, zutrittsbeschränkte Fahrzeughallen/Boxen mit protokolliertem Zugang.
- **Typische Nachweise:** Berechtigungskonzept Fahrzeugbereiche, Zutrittsprotokolle.
- **Vorlage:** P01; VA-17 Zutritt/Besucher.
- **Ressourcen:** Ggf. bauliche/technische Nachrüstung.
- **AL-Filter:** AL3 (hoher/sehr hoher Schutzbedarf)
## Control 8.1.6 — Einbruch-Überwachung
### 8.1.6-M1 — [MUSS]
**Anforderung:** Einbruchmeldeanlage nach DIN EN 50131/VdS mit Alarmverfolgung auf zertifizierten Sicherheitsdienst/Leitstelle — oder 24/7-Bewachung durch zertifizierten Sicherheitsdienst.
- **Organisatorisch:** Überwachungsvariante festlegen (EMA vs. Bewachung), Dienstleister vertraglich binden (zertifiziert).
- **Technisch:** EMA nach DIN EN 50131/VdS mit Aufschaltung auf Leitstelle (DIN 77200/VdS 3138); alternativ Wachdienst rund um die Uhr.
- **Typische Nachweise:** EMA-Attest/VdS-Nachweis, Aufschaltvertrag, Zertifikat Sicherheitsdienst, Wartungsnachweis.
- **Vorlage:** P01; R07 physische Sicherheit; R13 Lieferanten (Wachdienst); VA-10 Lieferanten.
- **Ressourcen:** EMA-Investition + laufende Aufschaltkosten oder Wachdienstvertrag.
- **AL-Filter:** AL2 | AL3
### 8.1.6-M2 — [MUSS]
**Anforderung:** Alarmierungspläne sind verfügbar.
- **Organisatorisch:** Alarmierungs-/Interventionsplan mit Eskalation, Verantwortlichen und Kontaktketten erstellen und aktuell halten.
- **Technisch:** Hinterlegung in Leitstelle/EMA; definierte Interventionskräfte.
- **Typische Nachweise:** Alarmierungsplan, Interventionsvereinbarung, Aktualisierungsnachweis.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Organisatorisch; Abstimmung mit Dienstleister.
- **AL-Filter:** AL2 | AL3
### 8.1.6-M3 — [MUSS]
**Anforderung:** Eine zeitnahe Alarmverfolgung ist sichergestellt.
- **Organisatorisch:** Reaktions-/Interventionszeiten vertraglich vereinbaren und überprüfen.
- **Technisch:** Aufschaltung auf 24/7-Leitstelle mit definierter Interventionszeit; Funktionstests.
- **Typische Nachweise:** SLA/Interventionsvereinbarung, Alarm-/Interventionsprotokolle, Testberichte.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Laufende Dienstleisterkosten.
- **AL-Filter:** AL2 | AL3
## Control 8.1.7 — Dokumentiertes Besuchermanagement
### 8.1.7-M1 — [MUSS]
**Anforderung:** Anmeldepflicht für alle Besucher.
- **Organisatorisch:** Besucherprozess mit Voranmeldung, Registrierung, Begleitung und Abmeldung definieren.
- **Technisch:** Besuchermanagementsystem oder Besucherbuch mit Ausweisvergabe; Protokollierung Kommen/Gehen.
- **Typische Nachweise:** Besucherprozess, Besucherprotokolle/-liste, Besucherausweise.
- **Vorlage:** P01; VA-17 Zutritt/Besucher.
- **Ressourcen:** Empfang/Werkschutz; ggf. Besuchersystem.
- **AL-Filter:** AL2 | AL3
### 8.1.7-M2 — [MUSS]
**Anforderung:** Dokumentierte Verpflichtung zur Geheimhaltung vor dem Zutritt.
- **Organisatorisch:** Besucher vor Zutritt auf Geheimhaltung verpflichten (NDA/Besuchererklärung), Aufbewahrung regeln.
- **Technisch:** Digitale Erfassung/Signatur im Besuchersystem oder unterschriebene Formulare.
- **Typische Nachweise:** Unterzeichnete Geheimhaltungserklärungen, Archiv der Erklärungen.
- **Vorlage:** P01; VA-17 Zutritt/Besucher; R13 Lieferanten (bei Fremdfirmen).
- **Ressourcen:** Organisatorisch gering.
- **AL-Filter:** AL2 | AL3
### 8.1.7-M3 — [MUSS]
**Anforderung:** Veröffentlichung von Sicherheits- und Besucherregelungen.
- **Organisatorisch:** Besucher-/Sicherheitsregeln am Empfang und im Sicherheitsbereich aushängen/aushändigen.
- **Technisch:** Aushänge, Merkblätter, Anzeige im Besuchersystem.
- **Typische Nachweise:** Aushang/Merkblatt, Fotodokumentation, Aushändigungsnachweis.
- **Vorlage:** P01; VA-17 Zutritt/Besucher.
- **Ressourcen:** Organisatorisch gering.
- **AL-Filter:** AL2 | AL3
### 8.1.7-M4 — [MUSS]
**Anforderung:** Länderspezifische gesetzliche Datenschutzbestimmungen einhalten.
- **Organisatorisch:** Besucherdatenverarbeitung datenschutzkonform gestalten (Rechtsgrundlage, Löschfristen, Information); mit DS-Funktion abstimmen.
- **Technisch:** Zugriffsbeschränkung und automatisierte Löschung der Besucherdaten.
- **Typische Nachweise:** Löschkonzept Besucherdaten, Datenschutzinformation, Eintrag im Verarbeitungsverzeichnis.
- **Vorlage:** P01; VA-17 Zutritt/Besucher; Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz.
- **Ressourcen:** Abstimmung DS-Funktion.
- **AL-Filter:** AL2 | AL3
## Control 8.1.8 — Mandantentrennung vor Ort
### 8.1.8-M1 — [MUSS]
**Anforderung:** Räumliche Trennung durch personelle/technische Maßnahmen nach Kunden/Projekten; ohne Trennung explizite Kundenfreigabe.
- **Organisatorisch:** Trennungskonzept je Kunde/Projekt definieren; bei fehlender Trennung Freigabe der betroffenen Kunden einholen und dokumentieren.
- **Technisch:** Bauliche Abtrennung (Boxen/Bereiche), zutrittsgetrennte Zonen, projektbezogene Berechtigungen.
- **Typische Nachweise:** Trennungskonzept, Zonen-/Berechtigungsplan, ggf. Kundenfreigaben.
- **Vorlage:** P01; R07 physische Sicherheit; R13 Lieferanten.
- **Ressourcen:** Ggf. bauliche Trennung.
- **AL-Filter:** AL2 | AL3
### 8.1.8-H1 — [HOCH]
**Anforderung:** Räumliche Situation auch geeignet für Mandantentrennung bei schutzbedürftig klassifizierten Fahrzeugen.
- **Organisatorisch:** Trennungskonzept auf Fahrzeugbereiche ausdehnen.
- **Technisch:** Separate, blickdichte und zutrittsgetrennte Fahrzeughallen/Boxen je Mandant.
- **Typische Nachweise:** Trennungskonzept Fahrzeuge, Belegungsplan, Fotodokumentation.
- **Vorlage:** P01; R07 physische Sicherheit.
- **Ressourcen:** Bauliche Maßnahmen bei hohem Schutzbedarf.
- **AL-Filter:** AL3 (hoher/sehr hoher Schutzbedarf)
## Control 8.2.1 — Geheimhaltungsvereinbarungen
### 8.2.1-M1 — [MUSS]
**Anforderung:** Eine Geheimhaltungsvereinbarung.
- **Organisatorisch:** NDA-Vorlage bereitstellen und Prozess festlegen, dass schutzbedürftige Informationen nur mit gültiger NDA weitergegeben werden.
- **Technisch:** Vertragsmanagement mit Ablage/Statusverfolgung der NDAs.
- **Typische Nachweise:** NDA-Vorlage, abgeschlossene NDAs, Vertragsregister.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Recht/Einkauf; organisatorisch.
- **AL-Filter:** AL2 | AL3
### 8.2.1-M2 — [MUSS]
**Anforderung:** NDA zwischen Auftragnehmer und Auftraggeber (Firmen-Ebene).
- **Organisatorisch:** Firmen-NDA vor Projektbeginn abschließen; Gültigkeit prüfen.
- **Technisch:** Ablage im Vertragsregister mit Laufzeitüberwachung.
- **Typische Nachweise:** Unterzeichnetes Firmen-NDA, Vertragsregister.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Recht/Einkauf.
- **AL-Filter:** AL2 | AL3
### 8.2.1-M3 — [MUSS]
**Anforderung:** Persönliche Verpflichtung aller Mitarbeiter und Projektbeteiligten.
- **Organisatorisch:** Alle Projektbeteiligten persönlich zur Geheimhaltung verpflichten (Onboarding/Projekteinstieg).
- **Technisch:** HR-/Projektsystem mit Erfassung und Nachverfolgung der Verpflichtungen.
- **Typische Nachweise:** Unterzeichnete Einzelverpflichtungen, Projektbeteiligtenliste mit Status.
- **Vorlage:** P01; R13 Lieferanten.
- **Ressourcen:** HR/Projektleitung.
- **AL-Filter:** AL2 | AL3
### 8.2.1-M4 — [MUSS]
**Anforderung:** Länderspezifische gesetzliche Datenschutzbestimmungen einhalten.
- **Organisatorisch:** Verpflichtungserklärungen datenschutzkonform gestalten und mit DS-Funktion abstimmen.
- **Technisch:** Zugriffsbeschränkte Ablage personenbezogener Verpflichtungsnachweise.
- **Typische Nachweise:** Datenschutzkonforme Formulare, Ablage-/Löschkonzept.
- **Vorlage:** P01; Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz.
- **Ressourcen:** Abstimmung DS-Funktion.
- **AL-Filter:** AL2 | AL3
## Control 8.2.2 — Beauftragung von Unterauftragnehmern
### 8.2.2-M1 — [MUSS]
**Anforderung:** Freigabe durch den ursprünglichen Auftraggeber.
- **Organisatorisch:** Prozess zur Einholung der Auftraggeber-Freigabe vor Beauftragung von Unterauftragnehmern etablieren.
- **Technisch:** Dokumentierte Freigaben im Vertrags-/Lieferantenmanagement.
- **Typische Nachweise:** Freigabedokument des Auftraggebers, Prozessbeschreibung.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Einkauf/Projektleitung.
- **AL-Filter:** AL2 | AL3
### 8.2.2-M2 — [MUSS]
**Anforderung:** Vertragsrechtlich gültige Geheimhaltungsvereinbarung vorhanden.
- **Organisatorisch:** NDA mit Unterauftragnehmer vor Weitergabe abschließen.
- **Technisch:** Vertragsregister mit Gültigkeitsprüfung.
- **Typische Nachweise:** Unterzeichnetes NDA, Vertragsregister.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Recht/Einkauf.
- **AL-Filter:** AL2 | AL3
### 8.2.2-M3 — [MUSS]
**Anforderung:** NDA zwischen Auftragnehmer und Unterauftragnehmer (Firmen-Ebene).
- **Organisatorisch:** Firmen-NDA mit Unterauftragnehmer sicherstellen.
- **Technisch:** Ablage/Statusverfolgung im Vertragsregister.
- **Typische Nachweise:** Firmen-NDA Unterauftragnehmer.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Recht/Einkauf.
- **AL-Filter:** AL2 | AL3
### 8.2.2-M4 — [MUSS]
**Anforderung:** Persönliche Verpflichtung aller Mitarbeiter/Projektbeteiligten des Unterauftragnehmers.
- **Organisatorisch:** Nachweis der persönlichen Verpflichtungen der Beschäftigten des Unterauftragnehmers einfordern.
- **Technisch:** Erfassung im Lieferantenmanagement.
- **Typische Nachweise:** Bestätigung/Liste der Einzelverpflichtungen des Unterauftragnehmers.
- **Vorlage:** P01; R13 Lieferanten.
- **Ressourcen:** Einkauf/Lieferantenmanagement.
- **AL-Filter:** AL2 | AL3
### 8.2.2-M5 — [MUSS]
**Anforderung:** Sicherstellung der Einhaltung der Sicherheitsvorgaben des eigentlichen Kunden (Nachweis eingeholt).
- **Organisatorisch:** Kundenvorgaben vertraglich an Unterauftragnehmer weitergeben und Nachweise einholen.
- **Technisch:** Back-to-back-Verträge, Nachweisablage.
- **Typische Nachweise:** Vertragliche Weitergabe, eingeholte Nachweise/Bestätigungen.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Einkauf/Recht.
- **AL-Filter:** AL2 | AL3
### 8.2.2-M6 — [MUSS]
**Anforderung:** Nachweis der Einhaltung der Mindestanforderungen Prototypenschutz des Unterauftragnehmers (z. B. Zertifikat).
- **Organisatorisch:** Nachweis (TISAX-Label Prototypenschutz/Bescheinigung) vor Beauftragung einholen und Gültigkeit prüfen.
- **Technisch:** Lieferantenregister mit Label-/Zertifikatsstatus und Ablaufüberwachung.
- **Typische Nachweise:** TISAX-Label/Zertifikat/Bescheinigung, Lieferantenbewertung.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Einkauf/Lieferantenmanagement.
- **AL-Filter:** AL2 | AL3
## Control 8.2.3 — Schulung/Sensibilisierung Umgang mit Prototypen
### 8.2.3-M1 — [MUSS]
**Anforderung:** Sicherstellung der Durchführung von Schulungen/Sensibilisierung durch die Leitung.
- **Organisatorisch:** Leitung verpflichtet sich zu Schulungsprogramm Prototypenschutz und stellt Ressourcen bereit.
- **Technisch:** Learning-Management/Schulungstracking zur Steuerung.
- **Typische Nachweise:** Managementbeschluss/Leitlinie, Schulungsplan.
- **Vorlage:** P01.
- **Ressourcen:** Leitung; Schulungsbudget.
- **AL-Filter:** AL2 | AL3
### 8.2.3-M2 — [MUSS]
**Anforderung:** Schulung bei Projekteinstieg.
- **Organisatorisch:** Erstschulung als Pflichtbestandteil des Projekt-Onboardings festlegen.
- **Technisch:** Onboarding-/LMS-Workflow mit Zutritts-/Freischaltvoraussetzung.
- **Typische Nachweise:** Onboarding-Schulungsnachweise, Teilnehmerlisten.
- **Vorlage:** P01.
- **Ressourcen:** Projektleitung/HR.
- **AL-Filter:** AL2 | AL3
### 8.2.3-M3 — [MUSS]
**Anforderung:** Regelmäßige (mind. jährliche) Schulung.
- **Organisatorisch:** Jährliche Wiederholungsschulung planen und einladen.
- **Technisch:** LMS mit Fälligkeits-/Erinnerungssteuerung.
- **Typische Nachweise:** Jahresschulungsplan, Teilnahmenachweise.
- **Vorlage:** P01.
- **Ressourcen:** Schulungsbudget/Zeit.
- **AL-Filter:** AL2 | AL3
### 8.2.3-M4 — [MUSS]
**Anforderung:** Sicherstellung der Kenntnisse zu Schutzbedarf und resultierenden Maßnahmen.
- **Organisatorisch:** Schulungsinhalte auf Schutzbedarfsklassen und konkrete Maßnahmen ausrichten; Verständnis prüfen.
- **Technisch:** Lernerfolgskontrolle/Quiz im LMS.
- **Typische Nachweise:** Schulungsunterlagen, Testergebnisse.
- **Vorlage:** P01.
- **Ressourcen:** Fachliche Contenterstellung.
- **AL-Filter:** AL2 | AL3
### 8.2.3-M5 — [MUSS]
**Anforderung:** Verpflichtende Teilnahme jedes Mitarbeiters/Projektbeteiligten.
- **Organisatorisch:** Teilnahmepflicht verankern und Eskalation bei Nichtteilnahme regeln.
- **Technisch:** LMS-Pflichtzuweisung mit Statusüberwachung.
- **Typische Nachweise:** Vollständigkeitsreport Teilnahme, Eskalationsnachweise.
- **Vorlage:** P01.
- **Ressourcen:** HR/Projektleitung.
- **AL-Filter:** AL2 | AL3
### 8.2.3-M6 — [MUSS]
**Anforderung:** Dokumentation der Durchführungen.
- **Organisatorisch:** Schulungsnachweise revisionssicher aufbewahren.
- **Technisch:** LMS-Reporting/Nachweisarchiv.
- **Typische Nachweise:** Teilnahmeprotokolle, Zertifikate, Schulungsregister.
- **Vorlage:** P01.
- **Ressourcen:** Organisatorisch gering.
- **AL-Filter:** AL2 | AL3
### 8.2.3-M7 — [MUSS]
**Anforderung:** Schulungskonzept Prototypenschutz ist Teil des allgemeinen Schulungskonzepts (vgl. IS 2.1.3).
- **Organisatorisch:** Prototypenschutz-Modul in das ISMS-Awareness-Konzept integrieren.
- **Technisch:** Gemeinsames LMS-Curriculum mit Prototypen-Modul.
- **Typische Nachweise:** Übergreifendes Schulungskonzept mit Prototypenmodul.
- **Vorlage:** P01.
- **Ressourcen:** Abstimmung ISB/HR.
- **AL-Filter:** AL2 | AL3
## Control 8.2.4 — Sicherheitseinstufung des Projekts bekannt
### 8.2.4-M1 — [MUSS]
**Anforderung:** Jedem Projektbeteiligten sind Sicherheitseinstufung und -vorgaben je Projektfortschritt bekannt.
- **Organisatorisch:** Sicherheitseinstufung und Vorgaben je Projektphase kommunizieren und aktualisieren.
- **Technisch:** Projektinfomappe/Portal mit stufenbezogenen Vorgaben.
- **Typische Nachweise:** Kommunikationsnachweise, Kenntnisnahmebestätigungen, Projektakte.
- **Vorlage:** P01.
- **Ressourcen:** Projektleitung.
- **AL-Filter:** AL2 | AL3
### 8.2.4-M2 — [MUSS]
**Anforderung:** Berücksichtigung von Stufenplänen, Geheimhaltung/Tarnung, Entwicklungsrichtlinien.
- **Organisatorisch:** Stufenplan und Tarn-/Entwicklungsvorgaben des Auftraggebers in Projektvorgaben aufnehmen.
- **Technisch:** Ablage der Stufenpläne im Projektsystem.
- **Typische Nachweise:** Stufenplan, Tarnvorgaben, Entwicklungsrichtlinien im Projekt.
- **Vorlage:** P01.
- **Ressourcen:** Projektleitung.
- **AL-Filter:** AL2 | AL3
### 8.2.4-M3 — [MUSS]
**Anforderung:** Berücksichtigung als IS-Anforderung des Projekts (vgl. IS 1.2.3 und 7.1.1).
- **Organisatorisch:** Prototypenanforderungen in die Projekt-IS-Anforderungen/-Risikobetrachtung überführen.
- **Technisch:** Verknüpfung mit ISMS-Projektrisikomanagement.
- **Typische Nachweise:** IS-Anforderungsliste/Risikoregister des Projekts.
- **Vorlage:** P01.
- **Ressourcen:** Abstimmung ISB/Projekt.
- **AL-Filter:** AL2 | AL3
## Control 8.2.5 — Prozess Zutrittsvergabe Sicherheitsbereiche
### 8.2.5-M1 — [MUSS]
**Anforderung:** Verantwortlichkeiten für die Zutrittsvergabe eindeutig geregelt und dokumentiert.
- **Organisatorisch:** Rollen für Beantragung, Genehmigung und Vergabe festlegen und dokumentieren.
- **Technisch:** Rollen-/Rechtematrix im Zutrittssystem.
- **Typische Nachweise:** Zuständigkeits-/Rollenmatrix, Prozessbeschreibung.
- **Vorlage:** P01; VA-17 Zutritt/Besucher.
- **Ressourcen:** Objektsicherheit.
- **AL-Filter:** AL2 | AL3
### 8.2.5-M2 — [MUSS]
**Anforderung:** Prozess bei Neuvergabe, Änderung und Löschung von Zutrittsberechtigungen.
- **Organisatorisch:** Lebenszyklusprozess (Antrag/Genehmigung/Änderung/Entzug, inkl. Austritt) definieren; regelmäßige Rezertifizierung.
- **Technisch:** Workflow im Zutrittssystem, automatischer Entzug bei Austritt.
- **Typische Nachweise:** Prozessbeschreibung, Vergabe-/Entzugsprotokolle, Rezertifizierungsnachweise.
- **Vorlage:** P01; VA-17 Zutritt/Besucher.
- **Ressourcen:** Objektsicherheit/HR-Schnittstelle.
- **AL-Filter:** AL2 | AL3
### 8.2.5-M3 — [MUSS]
**Anforderung:** Verhaltensregeln bei Verlust/Diebstahl von Schließmitteln.
- **Organisatorisch:** Meldeweg und Sofortmaßnahmen (Sperrung/Umstellung) festlegen.
- **Technisch:** Sofortsperrung elektronischer Medien; bei mechanischen Schlössern Schließzylindertausch.
- **Typische Nachweise:** Verfahrensanweisung, Verlustmeldungen, Sperr-/Tauschnachweise.
- **Vorlage:** P01; VA-17 Zutritt/Besucher.
- **Ressourcen:** Objektsicherheit; ggf. Zylindertausch-Budget.
- **AL-Filter:** AL2 | AL3
## Control 8.2.6 — Regelungen Bildaufzeichnung/Bildmaterial
### 8.2.6-M1 — [MUSS]
**Anforderung:** Genehmigungsverfahren zur Bildaufzeichnung.
- **Organisatorisch:** Genehmigungsprozess mit Verantwortlichen und Freigabekriterien definieren.
- **Technisch:** Antrags-/Freigabeworkflow, dokumentierte Freigaben.
- **Typische Nachweise:** Verfahrensbeschreibung, Freigabedokumente.
- **Vorlage:** P01.
- **Ressourcen:** Projektleitung/Objektsicherheit.
- **AL-Filter:** AL2 | AL3
### 8.2.6-M2 — [MUSS]
**Anforderung:** Klassifizierung/Einstufung von Bildmaterial festlegen.
- **Organisatorisch:** Einstufungsschema für Bildmaterial an Informationsklassifizierung anlehnen.
- **Technisch:** Kennzeichnung/Metadaten, Ablage nach Klassifizierung.
- **Typische Nachweise:** Klassifizierungsschema, klassifiziertes Bildmaterial.
- **Vorlage:** P01.
- **Ressourcen:** Organisatorisch.
- **AL-Filter:** AL2 | AL3
### 8.2.6-M3 — [MUSS]
**Anforderung:** Sichere Lagerung/Speicherung von Bildmaterial.
- **Organisatorisch:** Ablageorte und Zugriffsberechtigungen nach Need-to-know festlegen.
- **Technisch:** Verschlüsselte/zugriffsbeschränkte Speicherung, Berechtigungssteuerung.
- **Typische Nachweise:** Ablage-/Berechtigungskonzept, Zugriffsnachweise.
- **Vorlage:** P01.
- **Ressourcen:** IT/Objektsicherheit.
- **AL-Filter:** AL2 | AL3
### 8.2.6-M4 — [MUSS]
**Anforderung:** Sichere Löschung/Entsorgung nicht mehr benötigten Bildmaterials.
- **Organisatorisch:** Löschfristen und Löschprozess definieren.
- **Technisch:** Sichere Löschverfahren/Datenträgervernichtung mit Protokoll.
- **Typische Nachweise:** Löschkonzept, Lösch-/Vernichtungsprotokolle.
- **Vorlage:** P01.
- **Ressourcen:** IT/Objektsicherheit.
- **AL-Filter:** AL2 | AL3
### 8.2.6-M5 — [MUSS]
**Anforderung:** Abgesicherte Weitergabe/Versand nur an Empfangsberechtigte.
- **Organisatorisch:** Empfängerkreis und Freigabe für Versand definieren.
- **Technisch:** Verschlüsselter Transfer/gesicherte Freigabeplattform, Empfängerprüfung.
- **Typische Nachweise:** Versandregelung, Übermittlungsnachweise, Empfängerfreigaben.
- **Vorlage:** P01.
- **Ressourcen:** IT.
- **AL-Filter:** AL2 | AL3
## Control 8.2.7 — Mitführen/Nutzung mobiler Video-/Fotogeräte
### 8.2.7-M1 — [MUSS]
**Anforderung:** Festlegung für das Mitführen (z. B. mit/ohne Versiegelung).
- **Organisatorisch:** Regeln zum Mitführen mobiler Geräte in Sicherheitsbereichen festlegen (Versiegelung/Abgabe).
- **Technisch:** Kamera-Versiegelung, Verwahrung am Eingang, Kennzeichnung.
- **Typische Nachweise:** Regelung Mitführen, Versiegelungs-/Verwahrnachweise, Aushang.
- **Vorlage:** P01; VA-17 Zutritt/Besucher.
- **Ressourcen:** Objektsicherheit; Versiegelungsmaterial.
- **AL-Filter:** AL2 | AL3
### 8.2.7-M2 — [MUSS]
**Anforderung:** Festlegung für die Nutzung (z. B. Telefonieren, Fotografieren).
- **Organisatorisch:** Nutzungsregeln (Foto-/Aufnahmeverbot, Telefonie) je Bereich festlegen und kommunizieren.
- **Technisch:** Beschilderung/Kennzeichnung, Kontrollen durch Werkschutz.
- **Typische Nachweise:** Nutzungsregelung, Beschilderung, Kontrollprotokolle.
- **Vorlage:** P01; VA-17 Zutritt/Besucher.
- **Ressourcen:** Objektsicherheit.
- **AL-Filter:** AL2 | AL3
## Control 8.3.1 — Transporte nach Auftraggebervorgaben
### 8.3.1-M1 — [MUSS]
**Anforderung:** Prozess zur Einholung auftraggeberspezifischer Transportanforderungen beschrieben und implementiert.
- **Organisatorisch:** Prozess definieren, der vor Transport die Kundenvorgaben einholt und in Transportaufträge überführt.
- **Technisch:** Ablage der Vorgaben und Verknüpfung mit Transportaufträgen.
- **Typische Nachweise:** Prozessbeschreibung, eingeholte Kundenvorgaben.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Logistik/Projektleitung.
- **AL-Filter:** AL2 | AL3
### 8.3.1-M2 — [MUSS]
**Anforderung:** Vom Auftraggeber definierte Sicherheitsvorgaben sind bekannt und werden eingehalten.
- **Organisatorisch:** Vorgaben an ausführende Stellen/Dienstleister kommunizieren und Einhaltung überwachen.
- **Technisch:** Transportbegleitpapiere mit Sicherheitsanforderungen, Tracking.
- **Typische Nachweise:** Kommunikationsnachweis, Transportdokumentation, Kontrollen.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Logistik.
- **AL-Filter:** AL2 | AL3
### 8.3.1-M3 — [MUSS]
**Anforderung:** Nur vom Auftraggeber freigegebene Logistik-/Transportunternehmen verwenden.
- **Organisatorisch:** Freigegebene Dienstleister listen und ausschließlich diese beauftragen.
- **Technisch:** Lieferantenregister mit Freigabestatus, Sperrung nicht freigegebener.
- **Typische Nachweise:** Freigabeliste, Beauftragungsnachweise.
- **Vorlage:** P01; R13 Lieferanten; VA-10 Lieferanten.
- **Ressourcen:** Einkauf/Logistik.
- **AL-Filter:** AL2 | AL3
### 8.3.1-M4 — [MUSS]
**Anforderung:** Prozess zur Meldung aller sicherheitsrelevanten Ereignisse an den Auftraggeber.
- **Organisatorisch:** Meldeprozess mit Fristen und Kontaktketten zum Auftraggeber definieren.
- **Technisch:** Vorfall-/Meldeworkflow mit Dokumentation.
- **Typische Nachweise:** Meldeprozess, Vorfallsmeldungen/-protokolle.
- **Vorlage:** P01; R13 Lieferanten.
- **Ressourcen:** Logistik/Projektleitung.
- **AL-Filter:** AL2 | AL3
## Control 8.3.2 — Abstellen/Lagern nach Auftraggebervorgaben
### 8.3.2-M1 — [MUSS]
**Anforderung:** Auftraggebervorgaben zum Abstellen/Lagern sind nachweislich bekannt und werden eingehalten.
- **Organisatorisch:** Kundenvorgaben zu Lager-/Abstellbedingungen einholen, kommunizieren und Einhaltung prüfen.
- **Technisch:** Gesicherte, zutritts-/einblickgeschützte Abstell-/Lagerbereiche gemäß Vorgaben.
- **Typische Nachweise:** Vorgabendokument, Kenntnisnahmenachweise, Begehungs-/Kontrollprotokolle.
- **Vorlage:** P01; R07 physische Sicherheit; R13 Lieferanten.
- **Ressourcen:** Logistik/Objektsicherheit.
- **AL-Filter:** AL2 | AL3
## Control 8.4.1 — Tarnung von Versuchsfahrzeugen
> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen.
## Control 8.4.2 — Test-/Erprobungsgelände
> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen.
## Control 8.4.3 — Erprobungsfahrten öffentliche Straßen
> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen.
## Control 8.5.1 — Ausstellungen und Veranstaltungen
> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen.
## Control 8.5.2 — Film- und Fotoshootings
> Im aktuellen Prüfziel (Prototypenteile/-komponenten) n.a. — nur relevant bei Prüfziel Fahrzeuge/Erprobung/Veranstaltungen.
# Datenschutz (9.x)
## Control 9.1.1 — Richtlinien zum Datenschutz
### 9.1.1-M1 — [MUSS]
**Anforderung:** Richtlinie ist erstellt, wird regelmäßig aktualisiert und von der Leitung freigegeben.
- **Organisatorisch:** Datenschutzrichtlinie erstellen, durch Leitung freigeben, Review-Zyklus (mind. jährlich) und Verantwortliche festlegen; an Beschäftigte kommunizieren.
- **Technisch:** Versionierte Ablage im Dokumentenmanagement mit Freigabe-Workflow und Wiedervorlage.
- **Typische Nachweise:** Freigegebene Datenschutzrichtlinie, Freigabevermerk, Versions-/Reviewhistorie.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/Leitung; jährliche Pflege.
- **AL-Filter:** AL2 | AL3
## Control 9.2.1 — Verantwortlichkeiten für Datenschutz
### 9.2.1-M1 — [MUSS]
**Anforderung:** Bestellung eines DSB (sofern gesetzlich erforderlich, Art. 37 DSGVO) bzw. Festlegung einer Datenschutzfunktion.
- **Organisatorisch:** Prüfen, ob DSB-Pflicht besteht; DSB förmlich bestellen oder Datenschutzfunktion benennen; Aufgaben festlegen.
- **Technisch:** Ablage der Bestellurkunde/Funktionsbeschreibung im DMS.
- **Typische Nachweise:** Bestellurkunde/Benennung, Aufgabenbeschreibung, Meldung an Aufsichtsbehörde (falls DSB).
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** Leitung; ggf. externer DSB (Budget).
- **AL-Filter:** AL2 | AL3
### 9.2.1-M2 — [MUSS]
**Anforderung:** Veröffentlichung der Kontaktdaten (z. B. im Internet).
- **Organisatorisch:** Kontaktdaten der DS-Funktion/DSB veröffentlichen und aktuell halten.
- **Technisch:** Angabe in Datenschutzerklärung/Website, ggf. Meldung an Aufsichtsbehörde.
- **Typische Nachweise:** Website-/Impressumseintrag, Datenschutzerklärung, Behördenmeldung.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** Organisatorisch gering.
- **AL-Filter:** AL2 | AL3
### 9.2.1-M3 — [MUSS]
**Anforderung:** Eingliederung in die Unternehmensstruktur.
- **Organisatorisch:** Stellung der DS-Funktion (Weisungsfreiheit, direkte Berichtslinie an Leitung, Unabhängigkeit) im Organigramm verankern.
- **Technisch:** Dokumentation in Organigramm/Funktionsbeschreibung.
- **Typische Nachweise:** Organigramm, Rollen-/Funktionsbeschreibung.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** Organisatorisch.
- **AL-Filter:** AL2 | AL3
### 9.2.1-M4 — [MUSS]
**Anforderung:** Ausübung der Kontrollpflichten aus Art. 39 Abs. 1 lit. b) DSGVO und Dokumentation.
- **Organisatorisch:** Kontroll-/Überwachungsplan der DS-Funktion festlegen und durchführen.
- **Technisch:** Dokumentierte Audits/Kontrollen im DMS/Auditsystem.
- **Typische Nachweise:** Kontroll-/Auditplan, Prüfberichte, Maßnahmennachverfolgung.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion; Zeitaufwand.
- **AL-Filter:** AL2 | AL3
### 9.2.1-M5 — [MUSS]
**Anforderung:** Dokumentation des datenschutzrechtlichen Status und Bericht an die höchste Managementebene.
- **Organisatorisch:** Regelmäßige Datenschutzberichte an die Leitung etablieren.
- **Technisch:** Berichts-/Reportingablage.
- **Typische Nachweise:** Datenschutzberichte, Protokolle der Managementberichterstattung.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/Leitung.
- **AL-Filter:** AL2 | AL3
### 9.2.1-M6 — [MUSS]
**Anforderung:** Ausstattung mit ausreichenden Kapazitäten/Ressourcen (Qualifikation, Fortbildung, Fachliteratur, Koordinatoren).
- **Organisatorisch:** Ressourcen, Qualifikation, Fortbildungen und ggf. Datenschutzkoordinatoren je Bereich sicherstellen.
- **Technisch:** Zugang zu Fachliteratur/DS-Tools, Schulungssystem.
- **Typische Nachweise:** Fortbildungsnachweise, Ressourcen-/Budgetzuweisung, Koordinatorenbenennung.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** Budget Fortbildung/Personal.
- **AL-Filter:** AL2 | AL3
## Control 9.3.1 — Verzeichnis von Verarbeitungstätigkeiten
### 9.3.1-M1 — [MUSS]
**Anforderung:** Verzeichnis von Verarbeitungstätigkeiten (Art. 30 Abs. 1/2 DSGVO) mit Prozessbeschreibung und Zuständigkeiten.
- **Organisatorisch:** VVT erstellen und pflegen; bei Auftragsverarbeitung nur auftragsgegenständliche Angaben; Prozess mit Zuständigkeiten und Aktualisierung definieren.
- **Technisch:** VVT-Tool/Vorlage mit Änderungshistorie; Verknüpfung zu TOM (aus IS-Fragebogen).
- **Typische Nachweise:** Gepflegtes VVT, Prozessbeschreibung, Aktualisierungsnachweise.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion; ggf. VVT-Tool.
- **AL-Filter:** AL2 | AL3
## Control 9.4.1 — Datenschutzfolgenabschätzung
### 9.4.1-M1 — [MUSS]
**Anforderung:** Verarbeitungen, die eine DSFA benötigen, sind bekannt.
- **Organisatorisch:** Schwellwertanalyse/Kriterien zur DSFA-Pflicht festlegen und Verarbeitungen bewerten.
- **Technisch:** DSFA-Kennzeichnung im VVT/DS-Tool.
- **Typische Nachweise:** Schwellwertanalyse, Liste DSFA-pflichtiger Verarbeitungen.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion.
- **AL-Filter:** AL2 | AL3
### 9.4.1-M2 — [MUSS]
**Anforderung:** DSFA werden durchgeführt; Verantwortlichkeiten/Unterstützung festgelegt und bekannt.
- **Organisatorisch:** DSFA-Prozess mit Rollen, Unterstützung und Freigabe definieren; DSFA durchführen.
- **Technisch:** DSFA-Methodik/Vorlage, Dokumentation im DS-Tool.
- **Typische Nachweise:** Durchgeführte DSFA, Prozessbeschreibung, Maßnahmenkatalog.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/Fachbereiche.
- **AL-Filter:** AL2 | AL3
## Control 9.5.1 — Management der Datenübermittlung
### 9.5.1-M1 — [MUSS]
**Anforderung:** Prozesse/Arbeitsabläufe für Übermittlung (u. a. AV-Verträge Art. 28, Transferinstrumente, Zustimmung/Widerspruch bei Unterbeauftragung).
- **Organisatorisch:** Übermittlungsprozess mit Prüfung der Rechtsgrundlage, AV-Verträgen und Transferinstrumenten etablieren.
- **Technisch:** Vertrags-/Nachweismanagement mit Statusverfolgung.
- **Typische Nachweise:** AV-Verträge (Art. 28), SCC/TIA, Prozessbeschreibung, Zustimmungsnachweise.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/Recht.
- **AL-Filter:** AL2 | AL3
## Control 9.5.2 — Weitergabe vertraglicher Vereinbarungen an Unterauftragnehmer
### 9.5.2-M1 — [MUSS]
**Anforderung:** Mit Auftraggebern vereinbarte vertragliche Vereinbarungen werden an Unterauftragsverarbeiter weitergegeben.
- **Organisatorisch:** Back-to-back-Weitergabe der Auftraggebervorgaben an Unterauftragnehmer sicherstellen.
- **Technisch:** Vertragsregister mit Verknüpfung Haupt-/Unterauftrag.
- **Typische Nachweise:** Unterauftrags-AV-Verträge, Vertragsregister.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/Einkauf.
- **AL-Filter:** AL2 | AL3
### 9.5.2-M2 — [MUSS]
**Anforderung:** Überprüfung der Einhaltung vertraglicher Vereinbarungen; aktuelle Ansprechpartner-Kontaktdaten verfügbar.
- **Organisatorisch:** Regelmäßige Kontrolle der Unterauftragnehmer und Pflege der Ansprechpartner-Kontaktdaten.
- **Technisch:** Lieferantenregister mit Kontrollstatus und Kontaktdaten.
- **Typische Nachweise:** Kontroll-/Auditnachweise, aktuelle Kontaktliste.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; R13 Lieferanten; VA-18.
- **Ressourcen:** DS-Funktion/Lieferantenmanagement.
- **AL-Filter:** AL2 | AL3
## Control 9.5.3 — Datenübermittlung in Drittländer
### 9.5.3-M1 — [MUSS]
**Anforderung:** Drittlandübermittlungen sind bekannt und werden systematisch erfasst.
- **Organisatorisch:** Drittlandtransfers identifizieren und im VVT/Transferregister dokumentieren.
- **Technisch:** Kennzeichnung Drittlandtransfers im DS-Tool.
- **Typische Nachweise:** Transferübersicht, VVT-Einträge.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion.
- **AL-Filter:** AL2 | AL3
### 9.5.3-M2 — [MUSS]
**Anforderung:** Geeignete Garantien (Kapitel V DSGVO, EuGH-Rechtsprechung, ggf. TIA) liegen vor.
- **Organisatorisch:** Transferinstrumente je Drittlandtransfer festlegen und TIA bei Relevanz durchführen.
- **Technisch:** Ablage SCC/Angemessenheitsbeschluss/TIA im Vertrags-/DS-Tool.
- **Typische Nachweise:** SCC/Garantien, TIA, Angemessenheitsnachweise.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/Recht.
- **AL-Filter:** AL2 | AL3
### 9.5.3-M3 — [MUSS]
**Anforderung:** Prüfung, ob Zustimmung des Verantwortlichen zu jeder Drittlandübermittlung einzuholen ist.
- **Organisatorisch:** Zustimmungsprüfung als Prozessschritt vor Drittlandtransfer verankern.
- **Technisch:** Freigabe-/Zustimmungsworkflow mit Dokumentation.
- **Typische Nachweise:** Zustimmungsnachweise, Prozessbeschreibung.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion.
- **AL-Filter:** AL2 | AL3
## Control 9.6.1 — Betroffenenanfragen
### 9.6.1-M1 — [MUSS]
**Anforderung:** Betroffenenanfragen werden fristgerecht bearbeitet; Verfahren zur Unterstützung des Verantwortlichen; Mitarbeiterschulung zur Weiterleitung.
- **Organisatorisch:** Prozess zur Erkennung, Weiterleitung und fristgerechten Bearbeitung von Betroffenenanfragen etablieren; Mitarbeiter schulen, unverzüglich den Verantwortlichen zu kontaktieren.
- **Technisch:** Ticket-/Fallmanagement mit Fristenüberwachung.
- **Typische Nachweise:** Prozessbeschreibung, Fallakten mit Fristen, Schulungsnachweise.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion; ggf. Fallmanagement-Tool.
- **AL-Filter:** AL2 | AL3
## Control 9.6.2 — Datenschutzvorfälle
### 9.6.2-M1 — [MUSS]
**Anforderung:** Datenschutzvorfälle werden fristgerecht bearbeitet.
- **Organisatorisch:** Meldeprozess mit Fristen (u. a. 72-Stunden-Betrachtung) und Zuständigkeiten festlegen.
- **Technisch:** Vorfallmanagement mit Fristen-/Eskalationssteuerung.
- **Typische Nachweise:** Vorfallprozess, Vorfalldokumentation mit Fristen.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion.
- **AL-Filter:** AL2 | AL3
### 9.6.2-M2 — [MUSS]
**Anforderung:** Maßnahmen aus IS 1.6.1 berücksichtigen auch Datenschutzvorfälle, alternativ eigener Notfallplan.
- **Organisatorisch:** Datenschutzvorfälle in das ISMS-Incident-Management integrieren oder eigenen DS-Notfallplan erstellen.
- **Technisch:** Gemeinsames/verknüpftes Incident-Tool.
- **Typische Nachweise:** Incident-Prozess mit DS-Bezug bzw. DS-Notfallplan.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/ISB.
- **AL-Filter:** AL2 | AL3
### 9.6.2-M3 — [MUSS]
**Anforderung:** Etablierte/dokumentierte Verfahren: unverzügliche Meldung an Verantwortlichen, Prozessdokumentation, Mitarbeiterschulung, Unterstützung des Verantwortlichen.
- **Organisatorisch:** Meldeweg zum Verantwortlichen, Dokumentationspflichten und Mitarbeiterschulung festlegen.
- **Technisch:** Meldeworkflow mit Benachrichtigung des Verantwortlichen.
- **Typische Nachweise:** Verfahrensbeschreibung, Meldenachweise, Schulungsnachweise.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion.
- **AL-Filter:** AL2 | AL3
## Control 9.7.1 — Verpflichtung der Mitarbeiter auf Vertraulichkeit
### 9.7.1-M1 — [MUSS]
**Anforderung:** Mitarbeiter mit Bezug zu personenbezogenen Daten werden dokumentiert zur Vertraulichkeit (auch über das Arbeitsverhältnis hinaus) und Datenschutz verpflichtet.
- **Organisatorisch:** Vertraulichkeits-/Datenschutzverpflichtung in Onboarding aufnehmen und dokumentieren.
- **Technisch:** HR-System mit Erfassung/Nachverfolgung der Verpflichtungen.
- **Typische Nachweise:** Unterzeichnete Verpflichtungserklärungen, Vollständigkeitsübersicht.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** HR/DS-Funktion.
- **AL-Filter:** AL2 | AL3
## Control 9.7.2 — Schulung der Mitarbeiter zum Datenschutz
### 9.7.2-M1 — [MUSS]
**Anforderung:** Mitarbeiter sind geschult/sensibilisiert; Abstufung nach Schutzbedarf; spezifische Unterweisung kritischer Bereiche (z. B. IT-Admins).
- **Organisatorisch:** Datenschutz-Schulungskonzept mit Abstufung nach Schutzbedarf und rollenspezifischen Inhalten festlegen.
- **Technisch:** LMS mit Pflichtzuweisung, rollenspezifischen Modulen und Fälligkeitssteuerung.
- **Typische Nachweise:** Schulungskonzept, Teilnahmenachweise, rollenspezifische Unterweisungen.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/HR; Schulungsbudget.
- **AL-Filter:** AL2 | AL3
## Control 9.8.1 — Umgang mit Weisungen in Auftragsverarbeitungsverhältnissen
### 9.8.1-M1 — [MUSS]
**Anforderung:** Umgang mit Weisungen zur auftragsgegenständlichen Verarbeitung ist gewährleistet.
- **Organisatorisch:** Weisungsprozess mit definierten weisungsberechtigten/-empfangenden Stellen festlegen.
- **Technisch:** Dokumentierte Weisungsablage mit Nachverfolgung.
- **Typische Nachweise:** Weisungsprozess, dokumentierte Weisungen.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion.
- **AL-Filter:** AL2 | AL3
### 9.8.1-M2 — [MUSS]
**Anforderung:** Verfahren stellen sicher: Weisungen dokumentiert, umsetzbar (Berichtigen/Löschen), Daten nach Auftraggeber/Auftrag getrennt.
- **Organisatorisch:** Verfahren für Dokumentation, Umsetzung (Berichtigung/Löschung) und Mandantentrennung der Daten festlegen.
- **Technisch:** Mandantengetrennte Datenhaltung, Lösch-/Berichtigungsfunktionen, Protokollierung.
- **Typische Nachweise:** Verfahrensbeschreibung, Nachweis Datentrennung, Lösch-/Berichtigungsprotokolle.
- **Vorlage:** Richtlinie Datenschutz (D01) / R14 Compliance & Datenschutz; VA-18.
- **Ressourcen:** DS-Funktion/IT.
- **AL-Filter:** AL2 | AL3