78 lines
3.6 KiB
Markdown
78 lines
3.6 KiB
Markdown
# 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 Zeiteinheiten)?
|
||
- 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 Schreiboperation.
|
||
|
||
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". |