brain/02 Projekte/KMS/ISMS-Review Prompt.md

Auftrag: Strukturierte Überprüfung der ISMS-Software (TISAX-konform)

Kontext

siehe docs/tenant_data_context.md

Wichtigste Regel: KEINE Änderungen am Code

Du sollst in dieser Sitzung ausschließlich analysieren und vorschlagen.

• Keine Daten wird verändert, gelöscht, umbenannt oder neu angelegt ohne vorherige Freigabe durch mich (außer reinen Report-Dateien, siehe unten).
• Wenn du der Meinung bist, etwas müsste sofort geändert werden, schreibe das in den Report und warte auf meine Freigabe.

Was du tun sollst

1. Repository-Inventur (read-only)

• Liste die zentralen Entitäten (Asset, Information, Risiko, Prozess, Schutzbedarf, RTO, RPO, …) und überprüfe ihre Beziehungen auf Logik.
• Identifiziere, wo Klassifizierungen, RTO/RPO und Risikobewertungen technisch abgebildet sind.
• Identifiziere, wo sinnvollerweise weitere Beziehungen ergänzt werden sollten

2. Logik- und Konsistenz-Review

Prüfe insbesondere:

• Vertraulichkeitsvererbung: Wird die höchste Klassifizierung einer zugeordneten Information korrekt auf Asset/Prozess propagiert?
• RTO/RPO-Konsistenz: Ist Ist-RTO ≤ Soll-RTO logisch erzwungen oder zumindest sichtbar als Abweichung? Gleiches für RPO. Werden abhängige Assets/Prozesse mit härteren Anforderungen erkannt?
• Schutzbedarfsableitung: Ist die Ableitung Information → Asset → Prozess nachvollziehbar und nach Maximumprinzip umgesetzt?
• Risikologik: Eintrittswahrscheinlichkeit × Auswirkung, Risikobehandlung, Restrisiko, Akzeptanzschwellen — konsistent?
• Referentielle Integrität: Können verwaiste Zuordnungen entstehen (z. B. gelöschtes Asset, aber Risiko bleibt verknüpft)?

3. TISAX-/ISO-27001-Abdeckung (fachlich, nicht juristisch)

• Welche TISAX-/ISO-27001-typischen Pflichtfelder oder Workflows fehlen oder sind schwach abgebildet? Beispiele: Asset-Owner, Information-Owner, Klassifizierungsdatum, Wiederholungsprüfung, Auditspur, Versionierung von Risiken, Maßnahmenverfolgung, Wirksamkeitsprüfung.
• Hinweis: Du gibst fachliche Hinweise, keine Rechtsberatung.

4. Validierung & Datenqualität

• Wo fehlen Eingabevalidierungen (Pflichtfelder, Wertebereiche, Plausibilität RTO/RPO in Zeit­einheiten)?
• Wo könnte Müll-Daten entstehen (freie Textfelder statt Auswahllisten, inkonsistente Einheiten, fehlende Enums)?
• Gibt es eine Auditspur/Historie für sicherheitsrelevante Änderungen?

Output-Format

Lege eine einzige Markdown-Datei an: REVIEW_<heutiges-Datum>.md Diese Datei ist die einzige erlaubte Schreib­operation.

Struktur:

1. Executive Summary (max. 15 Zeilen)
2. Inventur: Module, Datenmodell-Übersicht
3. Findings, gruppiert nach den Abschnitten 2–5 oben. Pro Finding:
   • ID (F-001, F-002, …)
   • Titel
   • Schweregrad: kritisch / hoch / mittel / niedrig / hint
   • Betroffene Datei(en) und Zeilen
   • Beobachtung (was ist da)
   • Bewertung (warum ist das ein Problem)
   • Vorschlag (wie könnte man es lösen — noch nicht umsetzen!)
   • Risiko bei Umsetzung (was könnte dabei kaputtgehen)
4. Offene Fragen an mich — alles, wo du raten müsstest, stattdessen hier sammeln.
5. Vorgeschlagene Reihenfolge der Bearbeitung (was zuerst, was kann warten, was erst nach Rücksprache).

Vorgehen Schritt für Schritt

1. Beginne mit einem kurzen Plan, was du in welcher Reihenfolge anschauen wirst, und warte meine Bestätigung ab.
2. Wenn etwas unklar ist (z. B. welches Klassifizierungsschema gilt, ob Mehrmandantenfähigkeit Pflicht ist), frag nach, statt zu raten.
3. Halte dich strikt an „nur Vorschläge, keine Änderungen".