craftvia/docs/wizard-uebergabe/02_Fachcontent_C1-C9/C6_Umsetzungshinweise.md

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