| Prüfraster (streng) | **WAS · WIE · WO eindeutig dokumentiert · WER · NACHWEIS** — je Anforderung. „erfüllt" nur, wenn ALLE fünf Dimensionen konkret beantwortet sind **und** operative Prozesse auf eine VA bzw. zentral gepflegte Werte auf Register/Baseline verweisen. Sobald eine Dimension fehlt/vage/doppeldeutig ist → mindestens „teilweise". |
| Runde | **2 (Korrektur der zu milden Runde 1)** |
| Erstellt | 2026-07-22 |
| Status | Review-Report (read-only) — es wurde **nichts** am Vorlagenpaket geändert; nur diese Report-Datei wurde neu erzeugt. |
> Hinweis: Reiner Prüfbericht. Keine Datei des Vorlagenpakets, kein Code, keine DB, kein Seed wurde geändert; kein Commit, kein Push. Alle Textvorschläge sind einpflegefertig, aber **nicht** eingepflegt.
---
## 1. Management-Summary
Das Vorlagenpaket hat weiterhin einen **überdurchschnittlichen Reifegrad** (zentrale Baseline mit BL-IDs, zentrales Nachweisregister, 316 REQ-Anker ↔ 316 Mapping-IDs ohne Waisen, `-elev`-Blöcke für alle HOCH/SEHR-HOCH-Controls). Runde 1 hat diesen Reifegrad jedoch **zu wohlwollend** in Verdikte übersetzt: Sie hat Anforderungen als „erfüllt" gewertet, deren Umsetzungstext den strengen Rubric (eindeutiger Nachweisort, Inline-VA-Verweis, verwaltetes Register) nicht besteht. Runde 2 legt den skeptischen Maßstab konsequent an.
**Was gegenüber Runde 1 strenger/korrigiert wurde:**
- **8 Controls von „erfüllt" auf „teilweise" herabgestuft** (Details in §2): **1.2.3, 2.1.2, 3.1.1, 5.2.6, 5.2.8, 5.3.4-KI, 6.1.3, 7.1.2**. Die neue Control-Verteilung ist **14 erfüllt / 30 teilweise / 2 GAP** (Runde 1: 22 / 22 / 2).
- **Doppeldeutige Verortung** („im {{TOOL_TICKET}} **bzw.** ISMS-Tool") wird konsequent als **fehlender eindeutiger Nachweisort (G2)** gewertet — betrifft u. a. 1.2.3 und 1.6.1.
- **„Liste/Freigabeliste im ISMS-Tool"** ohne Register-ID, Pflichtattribute und Review-Turnus wird als **fehlendes verwaltetes Register (G4/G8)** gewertet — auch dort, wo Runde 1 „erfüllt" vergeben hatte (1.3.3, 1.3.4, 5.3.4, 5.3.4-KI, 6.1.3, 5.2.8, 5.2.7, 5.1.2).
- **Inline-VA-Verweis** wird control-genau geprüft: Von **23 Controls mit zuständiger VA** verweisen nur **8** im Umsetzungstext auf ihre VA; **15** nennen das Verfahren nur generisch bzw. im Anhang → G3.
**Die drei in Runde 1 bestätigten Misses — in Runde 2 sauber aufgearbeitet:**
1.**ISA 1.2.3 / R01 §3.3 (Informationssicherheit in Projekten):** In Runde 1 fälschlich „erfüllt". Tatsächlich deckt **keine VA** 1.2.3 ab (kein `FULFILLS 1.2.3` in den VA-Headern, kein Eintrag in `mapping.json → verfahren`). Der Umsetzungstext verortet doppeldeutig („die Einstufung wird im {{TOOL_TICKET}} **bzw. ISMS-Tool** dokumentiert"), und weder der genannte „dokumentierte Kriterienkatalog" noch ein **Projektregister/Projektverzeichnis** sind als verwaltetes Artefakt referenziert. → **Neu bewertet: teilweise**; Befund **G4** (neue VA „Informationssicherheit in Projekten") **+ G2/G8** (eindeutiger Nachweisort, Kriterienkatalog- und Projektregister). Textvorschläge in §8 (A-N1).
2.**Rendering-/Konsistenzbug `{{TOOL_TICKET}}` u. ä.:** Der Default von `{{TOOL_TICKET}}` ist **„das Ticketsystem"**; das Muster „im {{TOOL_TICKET}}" rendert daher zu **„im das Ticketsystem"** (Doppelartikel). Analog `{{TOOL_NAME}}` = „das ISMS-Tool" und `{{TOOL_IAM}}` = „das zentrale Verzeichnis …". Systemischer **G6**-Befund mit **11 konkreten Fundstellen** (§6), inkl. eines zusätzlichen Kasus-Fehlers bei `in {{TOOL_IAM}}` (R08:153).
3.**Software-Whitelist als verwaltetes Register mit Lieferantenbezug UND Asset-Kopplung:** Empfehlung **REG-SW-WHITELIST** mit Spalten u. a. Software, Version/Patch-Stand, **Quelle/Lieferant/Dienstleister**, Freigabestatus, Verantwortlich, Review — **doppelt cross-verlinkt** an **R13/VA-10 (Lieferantensteuerung)** (zugelassene Software hat einen steuerbaren Lieferanten) und an **R02/VA-08 (Asset & Klassifizierung)** (zugelassene Software ist als Asset geführt). Analog **REG-EXT-SERVICES** für externe/Cloud-/KI-Dienste (§5, §8 A-N3).
**Reifegrad-Einschätzung Runde 2:** Inhaltlich bleibt die Abdeckung auf Ebene der 312 konsolidierten ISA-Zeilen hoch; die Herabstufungen betreffen überwiegend **Nachweisführung und Verortung** (Inline-Verweis, verwaltetes Register, eindeutiger Ort), nicht fehlenden Sachinhalt. Zwei echte Inhalts-GAPs bleiben (**2.1.1**, **3.1.3**). Mit der Roadmap in §7 erreicht das Paket ein durchgängig audittaugliches Niveau.
> Die 46 Controls = 45 Controls in `mapping.json` **+** der „Phantom"-Control **3.1.3** (IMPL-Stub in R07 ohne `REQ`-Anker und ohne `mapping.json`-Eintrag; siehe GAP G-B2).
| **1.2.3** | R01 | erfüllt | **teilweise** | Keine VA deckt 1.2.3 ab; Verortung doppeldeutig („{{TOOL_TICKET}} bzw. ISMS-Tool"); Kriterienkatalog & Projektregister nicht als verwaltete Artefakte referenziert | G2, G4, G8, G6 |
| **2.1.2** | R05 | erfüllt | **teilweise** | „Ein Verfahren zum Umgang mit Verstößen ist beschrieben" — Verfahren nicht verortet/verlinkt (kein VA-/Dok-Verweis) | G1, G2 |
| **3.1.1** | R07 | erfüllt | **teilweise** | Zutrittsvergabe/-entzug (S1) und Besuchermanagement (S2) nur als „berücksichtigt" pauschaliert; kein Verfahren/VA verortet | G1, G3 |
| **5.2.6** | R10 | erfüllt | **teilweise** | VA-06 erfüllt laut `FULFILLS` 5.2.6-M1, wird im IMPL 5.2.6 aber **nicht** inline referenziert | G3 |
| **5.2.8** | R04 | erfüllt | **teilweise** | Kritische IT-Dienste nur „identifiziert"; kein verwaltetes Register (RTO/RPO nur im `-elev`-Block, keine BIA-Register-ID) | G8 |
| **5.3.4-KI** | R12 | erfüllt | **teilweise** | „Freigabeliste im ISMS-Tool" ist informelles Register ohne Register-ID/Attribute/Turnus (REG-EXT-SERVICES) | G8, G4 |
| **6.1.3** | R13 | erfüllt | **teilweise** | VA-10 erfüllt laut `FULFILLS` 6.1.3-M1, IMPL 6.1.3 verweist nicht inline; „Liste der IT-Dienste" (elev) informell | G3, G8 |
| **7.1.2** | R14 | erfüllt | **teilweise** | Kein referenzierter Prozess für Betroffenenrechte/Löschfristen-Review (nur BL-DEL-01 statisch); keine Datenschutz-Pflege-VA | G4 |
- **Inline-VA-Verweis:** 23 Controls haben eine zuständige VA; **8** verweisen inline (5.1.1, 5.2.4, 5.2.5*, 5.2.8, 5.2.9, 5.3.4, 5.3.4-KI, 6.1.1), **15** nicht (G3). *5.2.5 verweist auf VA-06, nicht auf das ebenfalls zuständige VA-04.
- **Leere Anforderung / Mapping-Bruch:** 3.1.3 (leerer `REQ`-Block, IMPL-Stub ohne Mapping); ISA **3.1.2** fehlt in R07 und `mapping.json` vollständig.
- **Strukturhinweis:** Control **1.1.1** (L00) hat **keinen gebündelten IMPL-Block**; `impl_anchor == req_anchor` — die „Umsetzung" ist die Leitlinien-Prosa selbst. Inhaltlich vertretbar (Leitlinie), aber vom übrigen `IMPL <control>`-Muster abweichend (siehe auch F-Tooling).
---
## 3. Vollständige Verlinkungs-/Coverage-Matrix — ALLE 46 Controls
Spalten: **Inline im Umsetzungstext verlinkt?** = verweist der `IMPL <control>`-Block per `{{LINK:VA-xx}}`/„siehe … Verfahren" auf die zuständige VA (ja) oder steht die VA nur generisch/im Anhang (nein); „n.a." = keine VA zuständig.
| # | Control | Anf.-Stufe(n) | Zuständige VA (FULFILLS) | Inline verlinkt? | Register/Baseline-Bezug | Status | Bemerkung |
| N2 | R05 | 2.1.2 | M/S | „Ein Verfahren zum Umgang mit Verstößen ist beschrieben" — Verfahren nicht verortet/verlinkt | G1, G2 | mittel | Verstoß-/Disziplinarverfahren benennen & verorten (Dok/VA-14) | „… ein dokumentiertes Verfahren zum Umgang mit Verstößen **(siehe {{LINK:VA-14}})** ist etabliert; Nachweis in der Personalakte." | {{LINK:VA-14}} / Personalakte |
| N3 | R07 | 3.1.1 | M/S/H | Besuchermanagement, Zutrittsvergabe/-entzug (S1/S2) nur als „berücksichtigt" pauschaliert | G1, G3 | mittel | Zutritts-/Besuchermanagement-Verfahren verorten | „… Zutrittsrechte werden über {{TOOL_TICKET}} vergeben/entzogen **(Ablauf siehe {{LINK:VA-17}})**; Besuchermanagement (Registrierung/Begleitung) ist geregelt (BL-PHY-…)." | Neue **VA-17** |
> Mehrere „Register" existieren heute implizit als Datensätze im ISMS-Tool. Empfehlung: als **benannte, verwaltete Register mit Register-ID** führen und über `{{LINK:REG-…}}` konsistent referenzieren (analog zur Baseline-/VA-Mechanik). Dazu Link-Auflösungstabelle (Integrationsleitfaden §6) und ggf. `variables.schema.json` um die neuen Ziele erweitern.
### 5.3 Ergänzung Baseline
| BL-ID | Parameter | Vorschlag |
|-------|-----------|-----------|
| **BL-GOV-01** | Audit-/Prüfzyklus | Interne Prüfung {{REVIEW_CYCLE}}; unabhängige Prüfung/Assessment mind. alle 3 Jahre bzw. nach grundlegenden Änderungen |
| **BL-PROJ-01** | Projekt-Klassifizierungskriterien | Dokumentierter Kriterienkatalog zur IS-Klassifizierung von Projekten (Auslöser/Schwellen für ISB-Einbindung) |
---
## 6. Konsistenz-/Rendering-Befunde (G6)
**Ursache:** Mehrere Variablen-Defaults beginnen bereits mit einem Artikel: `{{TOOL_TICKET}}`=„das Ticketsystem", `{{TOOL_NAME}}`=„das ISMS-Tool", `{{TOOL_IAM}}`=„das zentrale Verzeichnis (Entra ID / Active Directory)", `{{TECH_MDM}}`=„das eingesetzte MDM", `{{TECH_MFA}}`=„die eingesetzte MFA-Lösung" usw. Steht davor eine kontrahierte Präposition („im", „in"), entsteht beim Rendern ein **Doppelartikel** („im **das** Ticketsystem") bzw. ein Kasus-Fehler.
> **Zusätzlich doppeldeutig verortet (G2, „… bzw. ISMS-Tool"):** R01:110 („im {{TOOL_TICKET}} **bzw. ISMS-Tool**") und R04:69 („Formular im {{TOOL_TICKET}} **bzw. ISMS-Tool**"). Diese Stellen brechen den Grundsatz „ein Nachweisort je Sachverhalt" und sind Auslöser der Herabstufung von 1.2.3 (und Mitgrund bei 1.6.1).
>
> **Grammatikalisch unkritisch** (kein Fix nötig) sind Vorkommen ohne kontrahierte Präposition, z. B. „über {{TOOL_IAM}}", „und {{TOOL_TICKET}}", „{{TOOL_TICKET}}-Aufträge" — hier passt der eingebettete Artikel bzw. es entsteht keine Doppelung.
**Empfohlener Fix (zwei Varianten):**
- **Variante A (Text):** Präpositionsmuster „im {{VAR}}" → „**in {{VAR}}**" bzw. Artikel explizit ausschreiben: „**im Ticketsystem ({{TOOL_TICKET}})**". Bei R08:153 zusätzlich Kasus/Präposition „**im** {{TOOL_IAM}}" verwenden.
- **Variante B (Daten):** Variablen-Defaults ohne führenden Artikel definieren (`{{TOOL_TICKET}}`=„Ticketsystem") und Artikel im Fließtext setzen. **Achtung:** wirkt global auf alle Fundstellen; nur konsistent umsetzen.
---
## 7. Priorisierte Roadmap
**Priorität 1 — Inhalts-GAPs & Fehleinstufungen mit hoher Auditrelevanz:**
1.**N1 / VA-19 / REG-PROJECTS** — R01 1.2.3 Informationssicherheit in Projekten: VA anlegen, Kriterienkatalog (BL-PROJ-01) + Projektregister formalisieren, eindeutigen Ort setzen, Rendering fixen. *(Miss #1)*
> Projekte werden zu Beginn anhand des **dokumentierten Kriterienkatalogs (BL-PROJ-01)** hinsichtlich Informationssicherheitsbedarf klassifiziert; Einstufung, Risikobewertung und abgeleitete Maßnahmen werden im **Projektregister ({{LINK:REG-PROJECTS}})** geführt. In einer frühen Projektphase und bei Änderungen erfolgt eine Risikobewertung nach dem **Verfahren Informationssicherheit in Projekten ({{LINK:VA-19}})**; Maßnahmen werden als Aufgaben **in {{TOOL_TICKET}}** nachgehalten und vor Projektabschluss geprüft. Verantwortlich ist die Projektleitung; bei erhöhtem Schutzbedarf wird {{ROLE_ISB}} eingebunden.
*Hinweis:* Damit entfällt die doppeldeutige Verortung („{{TOOL_TICKET}} bzw. ISMS-Tool"), der Kriterienkatalog wird als Baseline-Artefakt (BL-PROJ-01) geführt, und die fehlende VA/das fehlende Register werden geschlossen.
> Sensible Arbeitsbereiche und Tätigkeiten sind im **Register sensibler Tätigkeiten ({{LINK:REG-SENS-ROLES}})** bestimmt und mit der geforderten Prüftiefe hinterlegt; Anforderungen an Positionen sind in Stellenbeschreibungen dokumentiert und werden erfüllt. Identitätsverifizierung sowie die persönliche und – bei sensiblen Rollen – erweiterte Eignungsprüfung (Gespräch, Referenzen, Führungszeugnis im rechtlich zulässigen Rahmen) erfolgen nach dem **Eignungs- und Verifizierungsverfahren ({{LINK:VA-14}})**; Verantwortlich: {{ROLE_HR_LEAD}}; Nachweis in der Personalakte.
**(a) Falls 3.1.3 im ISA-Scope ist** — Anforderungstext + Anker ergänzen und `mapping.json`-Einträge nachziehen:
> `<!-- REQ 3.1.3-M1 -->`
> - **[MUSS]** Der Umgang mit unterstützenden Betriebsmitteln (z. B. Verkabelung, Strom-/Klimaversorgung, Serverräume) ist bestimmt; Schutz gegen Ausfall, Wartung und Überwachung sind geregelt.
**(b) Falls 3.1.3 nicht im Scope ist** — Abschnitt 3.2 samt IMPL-Stub entfernen, damit kein Umsetzungstext ohne zugehörige Anforderung/Mapping verbleibt.
In beiden Fällen: Klären, ob **ISA 3.1.2** bewusst ausgelassen ist (fehlt in R07 und `mapping.json`) und dokumentieren.
> Software (inkl. Spezial-/Wartungssoftware) wird vor Einsatz freigegeben. Zugelassene Software wird im **Register Software-Whitelist ({{LINK:REG-SW-WHITELIST}})** mit Version/Patch-Stand, **Quelle/Lieferant**, Freigabestatus und Freigeber geführt; jeder Eintrag ist mit dem verantwortlichen **Lieferanten ({{LINK:VA-10}} / {{LINK:R13}})** und – als verwaltetes Asset – mit dem **Asset-Inventar ({{LINK:VA-08}} / {{LINK:R02}})** verknüpft. Beschaffung/Freigabe läuft über {{TOOL_TICKET}}; Repositorys sind gegen Manipulation geschützt; Verantwortlich: {{ROLE_IT_LEAD}}; Review {{REVIEW_CYCLE}}.
> … Cloud-/KI-Dienste werden vor Nutzung bewertet (Schutzbedarf, Datenlokation/EU, Verschlüsselung, Exit) und von {{ROLE_ISB}} freigegeben; Freigaben werden im **Register externe IT-/Cloud-/KI-Dienste ({{LINK:REG-EXT-SERVICES}})** mit Schutzbedarf, Datenlokation, **Quelle/Lieferant**, Freigabestatus und Freigeber geführt und mit **Lieferantensteuerung ({{LINK:VA-10}})** sowie **Asset-Inventar ({{LINK:VA-08}})** verknüpft (Ablauf siehe {{LINK:VA-11}}); die ausschließliche Nutzung freigegebener Dienste wird {{REVIEW_CYCLE}} geprüft.
> … das Verzeichnis der Verarbeitungstätigkeiten wird im ISMS-Tool ({{TOOL_NAME}}) geführt, TOM und Löschkonzepte (BL-DEL-01) sind geregelt; Rechtsregister-Review, Löschfristen und Betroffenenrechte werden nach dem **Datenschutz-/Compliance-Pflegeverfahren ({{LINK:VA-18}})** bearbeitet; Verantwortlich: {{ROLE_DPO}}.
> Die Einhaltung von Richtlinien, Verfahren und technischen Anforderungen wird organisationsweit nach dem **Audit-Programm ({{LINK:REG-AUDIT-PLAN}})** und dem **Audit-/Complianceprüfungs-Verfahren ({{LINK:VA-15}})** durch interne Audits und Kontrollen regelmäßig überprüft (Turnus BL-GOV-01); Ergebnisse werden aufgezeichnet und aufbewahrt, Abweichungen als Maßnahmen im {{TOOL_NAME}} nachverfolgt; Verantwortlich: {{ROLE_ISB}}.
> Informationssicherheitsanforderungen sind fester Bestandteil von Design, Beschaffung, Erweiterung und Änderung von IT-Diensten (Security by Design); Anforderungsspezifikation, Prüfung und Abnahmetests unter Sicherheitsaspekten erfolgen nach dem **Verfahren Sichere Beschaffung/Entwicklung & Abnahme ({{LINK:VA-16}})**; Produktivsetzung erst nach Prüfung **in {{TOOL_TICKET}}**. Produktivdaten in Tests werden vermieden/anonymisiert, Testsysteme angemessen geschützt.{{#if FLAG_DEV_INHOUSE}} Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews und automatisierten Sicherheitstests (SAST/Dependency-Scan) gemäß {{LINK:VA-16}}.{{/if}}
**Variante 1 (Daten an Leitfaden angleichen):** je Anforderung ein Feld `implementation` mit dem gebündelten Umsetzungstext (bzw. eindeutiger Kennung des Control-IMPL-Blocks) aufnehmen, damit der Assessment-Export (§8, „Implementation description") direkt aus `mapping.json` speisbar ist.
**Variante 2 (Leitfaden an Daten angleichen, geringerer Aufwand):** In §5/§8 dokumentieren, dass `implementation`**nicht** in `mapping.json` liegt, sondern zur Laufzeit über `impl_anchor` (control-gebündelter Anker `IMPL <control>`) aus der jeweiligen `.md` aufgelöst wird. **Zusätzlich klären:** Für Control **1.1.1** ist `impl_anchor == req_anchor` (kein `IMPL 1.1.1`-Block; Leitlinien-Prosa) — diese Sonderauflösung im Leitfaden explizit ausweisen.
### A-F18 — Trennung SEHR-HOCH in `-elev`-Blöcken (Muster)
Statt eines gemeinsamen `{{#if FLAG_ELEVATED_PROTECTION}}`-Blocks, der HOCH- und SEHR-HOCH-Sätze mischt:
So erscheint der SEHR-HOCH-Umsetzungstext nur, wenn auch die zugehörigen `[SEHR HOCH]`-Anforderungen im Set sind (betrifft u. a. IMPL 1.2.2-elev, 1.6.2-elev, 1.6.3-elev, 4.1.2-elev, 4.2.1-elev, 5.1.2-elev, 5.2.4-elev, 5.2.6-elev, 5.2.9-elev, 6.1.1-elev).
---
## 9. Positiv-Befunde (zur Absicherung, kein Handlungsbedarf)
- **Vorbildliche Referenzketten:** 5.1.1, 5.2.4, 5.2.8, 5.2.9, 6.1.1 verbinden IMPL ↔ VA ↔ Baseline eindeutig — Zielbild für die übrigen Controls.
- **Mapping-Integrität:** 316 REQ-Anker ↔ 316 Mapping-IDs, keine Waisen (verifiziert); VA-`FULFILLS`-Header stimmen mit `mapping.json → verfahren` überein.
- **Schutzbedarf:** `-elev`-Abdeckung für alle Controls mit HOCH/SEHR-HOCH-Anforderungen vorhanden (Trennungs-Feinschliff siehe F18).
- **KI-/GenAI-Ergänzung (R12 3.2)** inhaltlich stark und aktuell (Datenklassen je Dienst, kein Training auf Eingaben, Human-in-the-Loop, EU AI Act) — die Herabstufung von 5.3.4-KI betrifft ausschließlich die Register-Formalisierung, nicht den Sachinhalt.
@@ -40,7 +40,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.3.1 -->
<!-- IMPL 1.3.1 -->
Informationswerte und unterstützende Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar mit Attributen (Owner, Standort, Schutzbedarf) erfasst und als Katalog gepflegt; Zu-/Abgänge werden über {{TOOL_TICKET}} ausgelöst.
Informationswerte und unterstützende Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar mit Attributen (Owner, Standort, Schutzbedarf) erfasst und als Katalog gepflegt (siehe {{LINK:VA-08}}); Zu-/Abgänge werden über {{TOOL_TICKET}} ausgelöst.
### 3.2 Klassifizierung von Informationswerten (ISA 1.3.2)
### 3.2 Klassifizierung von Informationswerten (ISA 1.3.2)
@@ -60,7 +60,7 @@ Informationswerte und unterstützende Assets werden im ISMS-Tool ({{TOOL_NAME}})
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.3.2 -->
<!-- IMPL 1.3.2 -->
Es gilt ein konsistentes vierstufiges Klassifizierungsschema (Öffentlich / Intern / Vertraulich / Streng vertraulich) für Vertraulichkeit; die Einstufung erfolgt nach definierten Kriterien durch den Asset Owner im ISMS-Tool und berücksichtigt auch Integrität und Verfügbarkeit. Handhabungsvorgaben je Schutzklasse (Kennzeichnung, Speicherung, Transport, Übertragung BL-CRY-01/04, Löschung BL-DEL-01) sind definiert, umgesetzt und bekannt gemacht.
Es gilt ein konsistentes vierstufiges Klassifizierungsschema (Öffentlich / Intern / Vertraulich / Streng vertraulich) für Vertraulichkeit; die Einstufung erfolgt nach definierten Kriterien durch den Asset Owner im ISMS-Tool und berücksichtigt auch Integrität und Verfügbarkeit. Handhabungsvorgaben je Schutzklasse (Kennzeichnung, Speicherung, Transport, Übertragung BL-CRY-01/04, Löschung BL-DEL-01) sind definiert, umgesetzt und bekannt gemacht (siehe {{LINK:VA-08}}).
@@ -56,7 +56,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.4.1 -->
<!-- IMPL 1.4.1 -->
Das dokumentierte Risikomanagement-Verfahren mit Bewertungs- und Akzeptanzkriterien wird im ISMS-Tool ({{TOOL_NAME}}) umgesetzt: Risiken werden regelmäßig ({{REVIEW_CYCLE}}) und anlassbezogen identifiziert, bewertet (Eintritt × Schaden) und dokumentiert; je Risiko sind Risk Owner, Behandlungsoption und Maßnahmen mit Terminen hinterlegt und werden nachverfolgt. Restrisiken akzeptiert die {{ROLE_MANAGEMENT}} dokumentiert.
Das dokumentierte Risikomanagement-Verfahren (siehe {{LINK:VA-09}}) mit Bewertungs- und Akzeptanzkriterien wird im ISMS-Tool ({{TOOL_NAME}}) umgesetzt: Risiken werden regelmäßig ({{REVIEW_CYCLE}}) und anlassbezogen identifiziert, bewertet (Eintritt × Schaden) und dokumentiert; je Risiko sind Risk Owner, Behandlungsoption und Maßnahmen mit Terminen hinterlegt und werden nachverfolgt. Restrisiken akzeptiert die {{ROLE_MANAGEMENT}} dokumentiert.
### 3.2 Prüfung der Einhaltung im IS-Betrieb (ISA 1.5.1)
### 3.2 Prüfung der Einhaltung im IS-Betrieb (ISA 1.5.1)
@@ -66,7 +66,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.6.1 -->
<!-- IMPL 1.6.1 -->
Eine bekannte Definition meldepflichtiger Ereignisse und ein niedrigschwelliger Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool, E-Mail an {{ROLE_ISB}}, für gravierende Fälle Echtzeitkanal) stehen allen Beschäftigten und Externen zur Verfügung; der Meldeweg ist über Onboarding/Awareness (BL-HR-01) bekannt, ein Rückmeldeverfahren ist etabliert.
Eine bekannte Definition meldepflichtiger Ereignisse und ein niedrigschwelliger Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool, E-Mail an {{ROLE_ISB}}, für gravierende Fälle Echtzeitkanal) stehen allen Beschäftigten und Externen zur Verfügung; der Meldeweg ist über Onboarding/Awareness (BL-HR-01) bekannt, ein Rückmeldeverfahren ist etabliert (siehe {{LINK:VA-01}}).
{{#if FLAG_ELEVATED_PROTECTION}}
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.6.1-elev -->
<!-- IMPL 1.6.1-elev -->
@@ -123,7 +123,7 @@ Bei sehr hohem Schutzbedarf werden Tests und Übungen der Ereignismeldung regelm
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.6.2 -->
<!-- IMPL 1.6.2 -->
Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren im {{TOOL_TICKET}} kategorisiert, qualifiziert, priorisiert, behandelt und dokumentiert; Verantwortlichkeiten und Eskalationswege sind zugewiesen ({{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt um). Lessons Learned fließen in die Verbesserung ein; eine Strategie zur Behörden-/Strafverfolgungsmeldung besteht.
Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren (siehe {{LINK:VA-01}}) im {{TOOL_TICKET}} kategorisiert, qualifiziert, priorisiert, behandelt und dokumentiert; Verantwortlichkeiten und Eskalationswege sind zugewiesen ({{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt um). Lessons Learned fließen in die Verbesserung ein; eine Strategie zur Behörden-/Strafverfolgungsmeldung besteht.
{{#if FLAG_ELEVATED_PROTECTION}}
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 1.6.2-elev -->
<!-- IMPL 1.6.2-elev -->
@@ -192,7 +192,7 @@ Bei hohem Schutzbedarf sind maximale Reaktionszeiten je Schwere definiert, Eskal
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 1.6.3 -->
<!-- IMPL 1.6.3 -->
Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, Auslöse-/Eskalations-, Kommunikations- und Entscheidungswegen sowie strategischen Zielen ist etabliert; erforderliche Ressourcen sind verfügbar, Verantwortliche qualifiziert. Erkennungsmethoden bestehen, die Krisenplanung wird regelmäßig überprüft und aktualisiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.
Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, Auslöse-/Eskalations-, Kommunikations- und Entscheidungswegen sowie strategischen Zielen ist etabliert (Auslösung/Wiederanlauf siehe {{LINK:VA-02}}); erforderliche Ressourcen sind verfügbar, Verantwortliche qualifiziert. Erkennungsmethoden bestehen, die Krisenplanung wird regelmäßig überprüft und aktualisiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.
@@ -108,7 +108,7 @@ Alle Beschäftigten werden bei Eintritt vertraglich zur Vertraulichkeit und zur
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 2.1.3 -->
<!-- IMPL 2.1.3 -->
Ein von der Leitung genehmigtes, rollenspezifisches Schulungs-/Awareness-Konzept (BL-HR-01) ist etabliert; Beschäftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} sowie anlassbezogen geschult. Zielgruppen sind identifiziert, Teilnahmenachweise werden im {{TOOL_NAME}} geführt, Ansprechpartner für Informationssicherheit sind bekannt; die Wirksamkeit wird (z. B. Phishing-Simulation) geprüft.
Ein von der Leitung genehmigtes, rollenspezifisches Schulungs-/Awareness-Konzept (BL-HR-01) ist etabliert; Beschäftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} sowie anlassbezogen geschult (Ablauf siehe {{LINK:VA-12}}). Zielgruppen sind identifiziert, Teilnahmenachweise werden im {{TOOL_NAME}} geführt, Ansprechpartner für Informationssicherheit sind bekannt; die Wirksamkeit wird (z. B. Phishing-Simulation) geprüft.
@@ -42,7 +42,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 4.1.1 -->
<!-- IMPL 4.1.1 -->
Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden über den Lebenszyklus eindeutig personenbezogen und unter kontrollierten Bedingungen über {{TOOL_IAM}} vergeben; Ausgabe, Rücknahme und Sperrung werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07).
Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden über den Lebenszyklus eindeutig personenbezogen und unter kontrollierten Bedingungen über {{TOOL_IAM}} vergeben; Ausgabe, Rücknahme und Sperrung werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07, siehe {{LINK:VA-03}}).
{{#if FLAG_ELEVATED_PROTECTION}}
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 4.1.1-elev -->
<!-- IMPL 4.1.1-elev -->
@@ -150,7 +150,7 @@ Bei hohem Schutzbedarf sind Authentifizierung/Zugangskontrolle durch ergänzende
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 4.1.3 -->
<!-- IMPL 4.1.3 -->
Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) eindeutig personalisiert in {{TOOL_IAM}} verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen. Konten Ausgeschiedener werden unverzüglich deaktiviert, Konten regelmäßig überprüft (auch in Kundensystemen), Sammelkonten sind geregelt. Anmeldeinformationen werden sicher bereitgestellt; Standardkonten/-passwörter sind deaktiviert, Basiskonten mit Minimalrechten genutzt, Erstellung erfolgt im Vier-Augen-Prinzip, interaktive Anmeldung technischer Konten ist unterbunden.
Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) (siehe {{LINK:VA-03}}) eindeutig personalisiert in {{TOOL_IAM}} verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen. Konten Ausgeschiedener werden unverzüglich deaktiviert, Konten regelmäßig überprüft (auch in Kundensystemen), Sammelkonten sind geregelt. Anmeldeinformationen werden sicher bereitgestellt; Standardkonten/-passwörter sind deaktiviert, Basiskonten mit Minimalrechten genutzt, Erstellung erfolgt im Vier-Augen-Prinzip, interaktive Anmeldung technischer Konten ist unterbunden.
### 3.4 Zugriffsrechte (ISA 4.2.1)
### 3.4 Zugriffsrechte (ISA 4.2.1)
@@ -196,7 +196,7 @@ Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver)
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 4.2.1 -->
<!-- IMPL 4.2.1 -->
Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}}. Rechte werden bei Änderung/Wegfall aktualisiert bzw. entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05), auch in Kundensystemen; Standardkonten erhalten keine privilegierten Rechte.
Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}} (siehe {{LINK:VA-03}}). Rechte werden bei Änderung/Wegfall aktualisiert bzw. entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05), auch in Kundensystemen; Standardkonten erhalten keine privilegierten Rechte.
@@ -83,7 +83,7 @@ Bei hohem Schutzbedarf sind Anforderungen an die Schlüsselhoheit (insbesondere
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.1.2 -->
<!-- IMPL 5.1.2 -->
Genutzte Netzdienste sind identifiziert und dokumentiert; Richtlinien/Verfahren entsprechend der Klassifizierung sind umgesetzt. Informationen werden schutzbedarfsgerecht bei der Übertragung geschützt (mindestens {{TLS_MIN}}, BL-CRY-01), korrekte Adressierung sichergestellt und Fernzugriffe abgesichert; Regeln für E-Mail-/Dateiverschlüsselung sind definiert (BL-CRY-04).
Genutzte Netzdienste sind identifiziert und dokumentiert; Richtlinien/Verfahren entsprechend der Klassifizierung sind umgesetzt. Informationen werden schutzbedarfsgerecht bei der Übertragung geschützt (mindestens {{TLS_MIN}}, BL-CRY-01), korrekte Adressierung sichergestellt und Fernzugriffe abgesichert; Regeln für E-Mail-/Dateiverschlüsselung sind definiert (BL-CRY-04, Krypto-/Schlüsselverwaltung siehe {{LINK:VA-07}}).
@@ -54,7 +54,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 5.2.1 -->
<!-- IMPL 5.2.1 -->
Änderungen durchlaufen ein formales Change-Verfahren mit Antrag, Auswirkungs-/Risikobewertung, Planung, Test, Genehmigung, Rollback-Plan und Dokumentation im {{TOOL_TICKET}} (BL-OPS-09); Informationssicherheitsanforderungen sind bestimmt und erfüllt.
Änderungen durchlaufen ein formales Change-Verfahren (siehe {{LINK:VA-04}}) mit Antrag, Auswirkungs-/Risikobewertung, Planung, Test, Genehmigung, Rollback-Plan und Dokumentation im {{TOOL_TICKET}} (BL-OPS-09); Informationssicherheitsanforderungen sind bestimmt und erfüllt.
Anforderungen und Umfang technischer Prüfungen sind bestimmt und mit Betreibern/Nutzern abgestimmt; Systeme werden nach Härtungsvorgaben (BL-OPS-07, z. B. CIS-Benchmarks) konfiguriert und risikoorientiert geprüft. Ergebnisse werden nachvollziehbar gespeichert, der Leitung berichtet und Maßnahmen fristgerecht umgesetzt.
Anforderungen und Umfang technischer Prüfungen sind bestimmt und mit Betreibern/Nutzern abgestimmt; Systeme werden nach Härtungsvorgaben (BL-OPS-07, z. B. CIS-Benchmarks) konfiguriert und risikoorientiert geprüft (siehe {{LINK:VA-06}}). Ergebnisse werden nachvollziehbar gespeichert, der Leitung berichtet und Maßnahmen fristgerecht umgesetzt.
@@ -109,7 +109,7 @@ Bei hohem Schutzbedarf wird das Sicherheitsniveau des Lieferanten nachgewiesen (
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 6.1.2 -->
<!-- IMPL 6.1.2 -->
Vertraulichkeitsanforderungen sind bestimmt und bekannt; vor Weitergabe schutzbedürftiger Informationen werden gültige NDAs auf Basis geprüfter Standardvorlagen (mit Parteien, Informationsart, Gegenstand, Gültigkeit, Verantwortlichkeiten und nachvertraglichen Regelungen) abgeschlossen und im ISMS-Tool hinterlegt. Anforderungen/Verfahren und Gültigkeitsdauern werden regelmäßig überwacht, Nachweismöglichkeiten sind definiert.
Vertraulichkeitsanforderungen sind bestimmt und bekannt; vor Weitergabe schutzbedürftiger Informationen werden gültige NDAs auf Basis geprüfter Standardvorlagen (Ablauf siehe {{LINK:VA-10}}) (mit Parteien, Informationsart, Gegenstand, Gültigkeit, Verantwortlichkeiten und nachvertraglichen Regelungen) abgeschlossen und im ISMS-Tool hinterlegt. Anforderungen/Verfahren und Gültigkeitsdauern werden regelmäßig überwacht, Nachweismöglichkeiten sind definiert.
### 3.3 Abgrenzung der Verantwortlichkeiten (ISA 6.1.3)
### 3.3 Abgrenzung der Verantwortlichkeiten (ISA 6.1.3)
@@ -157,7 +157,7 @@ Vertraulichkeitsanforderungen sind bestimmt und bekannt; vor Weitergabe schutzbe
**Umsetzung bei {{ORG_NAME}}**
**Umsetzung bei {{ORG_NAME}}**
<!-- IMPL 6.1.3 -->
<!-- IMPL 6.1.3 -->
Betroffene IT-Dienste und ihre Sicherheitsanforderungen sind identifiziert; Verantwortlichkeiten zwischen der Organisation und externen IT-Dienstleistern (inkl. Mechanismen für geteilte Verantwortung) sind definiert, bekannt und werden erfüllt. Die Konfiguration ist anforderungsbasiert umgesetzt und dokumentiert, das Personal geschult.
Betroffene IT-Dienste und ihre Sicherheitsanforderungen sind identifiziert; Verantwortlichkeiten zwischen der Organisation und externen IT-Dienstleistern (inkl. Mechanismen für geteilte Verantwortung) sind definiert, bekannt und werden erfüllt (siehe {{LINK:VA-10}}). Die Konfiguration ist anforderungsbasiert umgesetzt und dokumentiert, das Personal geschult.
{{#if FLAG_ELEVATED_PROTECTION}}
{{#if FLAG_ELEVATED_PROTECTION}}
<!-- IMPL 6.1.3-elev -->
<!-- IMPL 6.1.3-elev -->
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Claude Opus 4.8