certvia/docs/SPEC.md

ISMS-Plattform – Umsetzungsspezifikation

Version 1.2 · Ergänzt gegenüber 1.1: Assets & BIA als ein gemeinsames Modul, zugeordnete Risiken in Asset-/Prozess-Detailansichten, ausgearbeitete Risiko-Detailansicht (Maßnahmen, betroffene Assets, Control-Verknüpfung, Verlauf).

Diese Datei ist die Projekt-Spec für die Umsetzung durch Claude Code. Sie beschreibt Architektur, Datenmodell, Module, Rollen, API und Akzeptanzkriterien. Sprache der Anwendung: Deutsch (i18n-fähig, EN vorbereitet).

0. Kontext & Leitentscheidungen

Es wird eine Web-Applikation zum Betrieb eines Informationssicherheits-Managementsystems (ISMS) entwickelt, die von mehreren Kunden (Mandanten) mit mehreren Nutzern und Rollen genutzt wird. Ausrichtung auf ISO/IEC 27001:2022 und TISAX / VDA-ISA 6.0.

Getroffene Entscheidungen (aus Anforderungsklärung):

Thema	Entscheidung
Betriebsmodell	Zentrale SaaS, Multi-Tenant (gemeinsame DB, Mandanten-ID + strikte Row-Level-Trennung)
Container	Betrieb in Docker (Compose), horizontal skalierbar
KI / Assistent + Chat	Cloud-LLM (Anthropic/OpenAI) über austauschbaren Provider-Adapter
Tech-Stack	Modernes Web-Frontend, Technologie offen → empfohlener Stack unten
Authentifizierung	Lokale Accounts (MVP) mit RBAC; SSO (OIDC/SAML) als spätere Erweiterung vorbereiten
Umfang	Alle Module gleichwertig (kein hartes Phasing), aber sinnvolle Iterationsreihenfolge
Norm-Inhalte	ISO 27001:2022 Annex A (93 Controls) vorbefüllt + SoA; VDA-ISA Struktur/Mapping vorbereitet, Katalog-Inhalte per Import (lizenzrechtlich, siehe §12)
Sprache	Deutsch, i18n-ready
UX	Modern, einfach, geringe Komplexität, Drag-and-Drop, grafische Oberflächen

1. Empfohlener Tech-Stack

Ziel: eine Codebasis, geringe Betriebs- und Wartungskomplexität, moderne UX.

• Frontend & Backend: Next.js 15 (App Router, React 19, TypeScript) — SSR + API in einem Deployment.
• API-Layer: tRPC (typsicher) oder REST (OpenAPI). Empfehlung: tRPC intern, zusätzlich schlanke REST-Endpunkte für Integrationen/Webhooks.
• ORM/DB: Prisma + PostgreSQL 16. Vektorsuche für den Chat/RAG über pgvector (kein zusätzlicher Vektor-DB-Dienst nötig).
• Auth: Auth.js (NextAuth) mit Credentials-Provider (lokale Accounts), Argon2id-Hashing, TOTP-2FA. OIDC/SAML-Provider als Feature-Flag vorbereitet.
• Hintergrundjobs / wiederkehrende Aufgaben: BullMQ + Redis (Scheduler für Reviews, Audits, Fristen, Erinnerungen).
• Dateispeicher: S3-kompatibel (MinIO im Compose-Stack), verschlüsselt.
• UI-Kit: Tailwind CSS + shadcn/ui, Icons via lucide-react, Diagramme via Recharts.
• Drag-and-Drop: dnd-kit (Kanban-Boards, Risiko-Matrix-Einordnung, Aufgaben, Datei-Uploads).
• KI-Anbindung: Provider-Adapter (AiProvider-Interface) für Anthropic/OpenAI; RAG-Pipeline auf Dokumenten des Mandanten.
• E-Mail: SMTP (Benachrichtigungen, Fristen, Eskalationen).
• Tests: Vitest (Unit), Playwright (E2E). Linting: ESLint + Prettier.

Alternative bei starkem KI-/Analytics-Fokus: zusätzlicher Python-FastAPI-Microservice nur für RAG/Embedding. Für geringe Komplexität zunächst nicht empfohlen — alles in Next.js.

2. Architektur (High-Level)

                 ┌─────────────────────────────────────────────┐
   Browser ───▶  │  Next.js (App Router)                        │
   (DE UI)       │  - React UI (Tailwind + shadcn/ui, dnd-kit)  │
                 │  - tRPC/REST API                             │
                 │  - Auth.js (RBAC, Mandanten-Guard)           │
                 └───────┬───────────────┬──────────────┬───────┘
                         │               │              │
                    Prisma           BullMQ         AiProvider
                         │           (Worker)       (Adapter)
                 ┌───────▼───────┐  ┌───▼────┐   ┌────▼─────────┐
                 │ PostgreSQL 16 │  │ Redis  │   │ Anthropic /   │
                 │  + pgvector   │  │        │   │ OpenAI API    │
                 └───────────────┘  └────────┘   └──────────────┘
                 ┌───────────────┐
                 │ MinIO (S3)     │  Dokumente, Nachweise, Uploads
                 └───────────────┘

Mandantenfähigkeit (Multi-Tenant): Jede fachliche Tabelle trägt tenant_id. Zugriff ausschließlich über einen zentralen Prisma-Middleware-/Query-Guard, der tenant_id aus der Session erzwingt (Row-Level-Isolation). Zusätzlich Postgres Row Level Security (RLS) als zweite Verteidigungslinie. Kein Query ohne Mandantenkontext.

3. Rollen- und Rechtemodell (RBAC)

Rollen sind pro Mandant vergeben. Ein Nutzer kann mehrere Rollen haben.

Rolle	Beschreibung	Kernrechte
Plattform-Admin (mandantenübergreifend)	Betreiber der SaaS	Mandanten anlegen/sperren, globale Kataloge pflegen, keine Einsicht in Kundendaten außer für Support (protokolliert)
Mandanten-Admin	Kundenadministrator	Nutzer/Rollen im Mandanten verwalten, Stammdaten, Konfiguration
ISB / CISO	Informationssicherheitsbeauftragter	Vollzugriff fachlich: Risiken, Assets, BIA, Maßnahmen, Vorfälle, Freigaben, Chat-Eskalationsziel
Auditor (intern/extern)	Prüfer	Lesezugriff + Audit-Durchführung, Findings anlegen, keine Bearbeitung der Fachdaten
Asset-/Risk-Owner	Fachverantwortliche	Bearbeitung zugewiesener Assets/Risiken/Maßnahmen
Mitarbeiter / User	Standardnutzer	Chat nutzen, Richtlinien lesen, Vorfälle melden, eigene Aufgaben

Rechte werden als granulare Permissions (asset:read, risk:write, incident:manage, …) implementiert und über Rollen gebündelt. UI blendet nicht-erlaubte Aktionen aus; API prüft serverseitig.

4. Module (funktionaler Kern)

4.1 Assets & BIA (ein gemeinsames Modul)

Asset-Inventar und Business Impact Analyse bilden ein zusammenhängendes Modul (gemeinsamer Navigationsbereich, durchgängige Detailansichten). Assets, Prozesse und deren Kritikalität werden im selben Kontext gepflegt.

4.1.1 Asset-Inventar

Zentrales Verzeichnis aller Werte (Assets): Informationen, Systeme, Anwendungen, Standorte, Lieferanten, Personen/Rollen, Datenkategorien.

• Attribute: Name, Typ, Owner, Standort/Prozesszuordnung, Klassifizierung (C/I/A — Vertraulichkeit/Integrität/Verfügbarkeit als Schutzbedarf 1–4), Lieferanten/Verantwortliche, Status, Tags.
• Beziehungen zwischen Assets (Abhängigkeiten) modellierbar → speist BIA und Risiko.
• Import/Export (Excel/CSV), Bulk-Bearbeitung, Versionshistorie.
• Grafische Ansicht: filterbare Tabelle + optionale Abhängigkeits-/Netzwerkgrafik.
• Asset-Detailansicht zeigt neben Stammdaten und Beziehungen auch:
  • Zugeordnete Risiken (mit Risikowert, Status, Behandlung) inkl. Absprung in die Risiko-Detailansicht,
  • zugeordnete Prozesse (mit Rolle primär/sekundär) und daraus vererbter Schutzbedarf,
  • verknüpfte Maßnahmen, Vorfälle und Nachweise.

4.1.2 Business Impact Analyse (BIA)

Ermittelt Kritikalität von Prozessen/Assets und Wiederanlaufparameter.

• Erfassung von Geschäftsprozessen, Zuordnung zu Assets.
• Asset-Rollen je Prozess (Detailansicht): In der Prozess-Detailansicht werden die zugeordneten Assets nach Rolle unterschieden:
  • Primäres Asset = das im Prozess erzeugte/verantwortete Ergebnis-Asset (z. B. der erzeugte Datensatz/das Informationsobjekt). Genau ein oder wenige je Prozess.
  • Sekundäre Assets = alle unterstützenden Assets, die zur Prozessdurchführung benötigt werden (Systeme, Anwendungen, Infrastruktur, Personen/Rollen, Lieferanten).
  • Die Rollenzuordnung speist die Abhängigkeitsanalyse (siehe 4.11) und die Schutzbedarfsvererbung: Der Schutzbedarf des primären Assets/Prozesses vererbt sich auf die sekundären Assets (max. Prinzip).
• Schadensszenarien und Schadenshöhe je Schutzziel und Zeitverlauf.
• Kennzahlen: RTO, RPO, MTD/MTPD, maximal tolerierbarer Ausfall.
• Ergebnis: Kritikalitätsstufe je Prozess/Asset → priorisiert Risikoanalyse und Maßnahmen.
• Prozess-Detailansicht zeigt zusätzlich die zugeordneten Risiken des Prozesses und seiner Assets (aggregiert, mit Risikowert und Status).
• Geführter Wizard (Schritt-für-Schritt), Ergebnis als Report exportierbar.

4.2 Risikoanalyse & -behandlung

Aufbauend auf Assets + BIA.

• Risiken = (Asset/Prozess) × Bedrohung × Schwachstelle.
• Bewertung: Eintrittswahrscheinlichkeit × Auswirkung → Risikowert; konfigurierbare Skalen (z. B. 5×5).
• Interaktive Risiko-Matrix (Heatmap) mit Drag-and-Drop-Einordnung/Filter.
• Risikobehandlung: Vermeiden / Vermindern / Übertragen / Akzeptieren; Maßnahmen (Controls) verknüpfen.
• Rest-Risiko nach Maßnahme, Risikoakzeptanz mit Freigabe-Workflow (ISB/Leitung).
• Vererbung: Schutzbedarf aus Asset/BIA wird vorbelegt.
• Verknüpfung zu ISO-27001-Annex-A-Controls und VDA-ISA-Zielen (SoA-Bezug).
• Risiko-Detailansicht (vollständig):
  • Stammdaten: Beschreibung, Bedrohung/Schwachstelle, Owner, Status, Termine/Reviews.
  • Bewertung: Brutto-Risiko (Wahrscheinlichkeit × Auswirkung), Rest-Risiko nach Maßnahmen, Bewertungshistorie (Verlauf des Risikowerts über Zeit).
  • Notwendige/verknüpfte Maßnahmen: Liste der behandelnden Maßnahmen mit Status, Fälligkeit und Owner; neue Maßnahme direkt aus dem Risiko heraus anlegbar.
  • Betroffene Assets/Prozesse: alle verknüpften Assets und Prozesse mit Schutzbedarf/Kritikalität, Absprung in deren Detailansichten.
  • Verknüpfte Annex-A-Controls / VDA-ISA-Ziele (SoA-Bezug) und ggf. auslösende Vorfälle.
  • Freigabe-/Akzeptanz-Workflow mit Kommentar und Audit-Trail.

4.3 Control-Kataloge & Statement of Applicability (SoA)

• ISO 27001:2022 Annex A mit 93 Controls in 4 Themen (Organisatorisch 37, Personenbezogen 8, Physisch 14, Technologisch 34) vorbefüllt.
• SoA: je Control Anwendbarkeit (ja/nein + Begründung), Umsetzungsstatus, Verweise auf Maßnahmen/Nachweise, Verantwortliche.
• VDA-ISA 6.0: 9 Kapitel/Prüfziele als Struktur + Mapping-Tabelle ISO↔VDA-ISA (siehe §12 zur Lizenz).
• Reifegrad-Bewertung (VDA-ISA-Reifegradmodell 0–5) je Prüfziel.

4.4 Maßnahmenverwaltung (Controls/Tasks)

• Maßnahmen mit Owner, Fälligkeit, Status, Priorität, Nachweisen (Dateien).
• Kanban-Board (Drag-and-Drop) und Listen-/Kalenderansicht.
• Verknüpfung zu Risiken, Controls, Vorfällen, Audits.
• Maßnahmen-Detailansicht zeigt die zugeordneten Risiken (welche Risiken behandelt diese Maßnahme, mit Risikowert vor/nach) sowie verknüpfte Controls, Vorfälle und Nachweise.

4.5 Wiederkehrende Aufgaben & Fristen (Scheduler)

Automatische Erzeugung/Erinnerung für u. a.:

• Benutzer-/Zugriffs-Review (z. B. quartalsweise),
• Interne Audits und externe Audits/Re-Zertifizierung (Zyklen),
• Management-Review, Richtlinien-Review, Risiko-Review, Lieferanten-Review.
• Konfigurierbare Wiederholung (cron-artig), Zuweisung, Eskalation bei Überfälligkeit, E-Mail-Benachrichtigung, Dashboard-Fälligkeitsanzeige.

4.6 Richtlinien-Management & Implementierungs-Assistent

• Richtlinien-Bibliothek mit Versionierung, Freigabe- und Lese-Bestätigungs-Workflow.
• KI-Assistent führt Nutzer durch die Anpassung von Muster-Richtlinien an das eigene Unternehmen.
• Zwei Individualisierungs-Ebenen:
  1. Basisdaten/Metadaten: Firmenname, verantwortliche Rollen, Geltungsbereich, Platzhalter.
  2. Inhaltliche Anpassung der Klauseln: Die KI formuliert und passt die eigentlichen Richtlinientexte (Klauseln/Abschnitte) auf Basis der Unternehmensangaben an (z. B. erlaubte Geräte, Fristen, Verantwortlichkeiten, branchenspezifische Anforderungen). Vorschläge sind akzeptier-/verwerfbar.
• Inline-Editor (WYSIWYG): Nutzer bearbeiten die generierten Klauseltexte direkt im Tool; KI-Assistenz („umformulieren", „kürzen", „an Control X ausrichten") auf Absatzebene.
• In-Tool-Darstellung: Die Richtlinie wird innerhalb der Anwendung gerendert lesbar dargestellt (formatierte Ansicht, Inhaltsverzeichnis, verknüpfte Controls), nicht nur als Download.
• Governance: Versionierung mit Änderungsverlauf/Diff, Freigabe-Workflow, Lesebestätigung durch Mitarbeiter, Verknüpfung zu ISO-/VDA-Controls.
• Export als PDF/DOCX; Ablage in der Richtlinien-Bibliothek; Anbindung an den Chat (RAG) als Wissensquelle.

4.7 Interaktiver Chat (RAG + Eskalation)

• Nutzer stellen Fragen; der Chat sucht per RAG in der Dokumentation/Richtlinien des Mandanten (pgvector) und antwortet mit Quellenangabe.
• Wenn keine belastbare Antwort/Berechtigung → Eskalation/Ticket an den ISB (Weiterleitung, Benachrichtigung, Nachverfolgung).
• Nur mandanten-eigene Dokumente im Kontext; keine mandantenübergreifende Vermischung.

4.8 Sicherheitsvorfall-Management (Incident)

• Meldung von Vorfällen (auch niedrigschwellig durch Mitarbeiter, Formular + Chat).
• Workflow: Erfassung → Triage/Kategorisierung → Bearbeitung → Eskalation → Abschluss → Lessons Learned.
• Schweregrad, betroffene Assets, SLA/Fristen, Aufgaben, Zeitleiste, Nachweise.
• Verknüpfung zu Risiken (neue/erhöhte Risiken) und ggf. Meldepflichten-Hinweis.

4.9 Dashboards & Reporting

• Rollenbezogene Dashboards (ISB, Auditor, Owner): offene Risiken, überfällige Aufgaben, SoA-Erfüllungsgrad, Reifegrade, Vorfälle.
• Exporte: SoA, Risikoregister, Maßnahmenplan, Audit-Report, Management-Review — als PDF/Excel.

4.10 Audit-Management

• Audit-Plan (intern/extern), Scope, Prüfpunkte (aus Katalogen), Findings, Maßnahmen aus Findings, Nachverfolgung, Audit-Report.

4.11 Abhängigkeits- & Kritische-Pfade-Analyse

Visualisiert die Verkettung von Prozessen und Assets, um Single Points of Failure und kritische Pfade sichtbar zu machen.

• Netzwerkgraph: Knoten = Prozesse und Assets (primär/sekundär), Kanten = Abhängigkeiten (aus Asset-Relationen und BIA-Rollenzuordnung).
• Kritische Pfade werden anhand von Kritikalität/Schutzbedarf (aus BIA) berechnet und farblich hervorgehoben; Engstellen (Assets, von denen viele kritische Prozesse abhängen) werden markiert.
• Interaktiv: Filtern nach Prozess/Kritikalität, Knoten anklicken → Detail/Sprung zum Asset, Hervorheben aller abhängigen Elemente.
• Speist Risikoanalyse (Konzentrationsrisiken) und BCM/Notfallplanung.
• Umsetzungshinweis: Rendering mit einer Graph-Bibliothek (z. B. Cytoscape.js oder D3-Force); Datenbasis sind AssetRelation und die BIA-Primär-/Sekundär-Zuordnung.

4.12 Nachweis- & Dokumentenmanagement

• Zentrale, auditfeste Ablage für Nachweise/Evidenzen (Dateien, Screenshots, Protokolle).
• Verknüpfung eines Nachweises mit Controls (SoA), Maßnahmen, Audits, Risiken und Vorfällen.
• Metadaten: Gültigkeit/Ablaufdatum, Verantwortliche, Version, Vertraulichkeit; Erinnerung bei ablaufenden Nachweisen.
• Volltext-/Metadatensuche; Nachweise sind Quelle für den RAG-Chat.

4.13 Lieferanten- & Dienstleister-Management (Third-Party)

Für TISAX besonders relevant.

• Verzeichnis externer Dienstleister/Lieferanten mit Kontakt, Leistungen, Kritikalität.
• Sicherheitsbewertung/Fragebögen, Zertifikatsnachweise (z. B. ISO 27001/TISAX-Label), Ablaufüberwachung.
• Vertrags-/AV-Verwaltung (DSGVO Art. 28), Wiedervorlage/Review-Zyklen (siehe wiederkehrende Aufgaben).
• Verknüpfung zu Assets (welcher Dienstleister betrifft welche Assets) und Risiken (Third-Party-Risiko).

4.14 Management-Review & Kennzahlen (KPIs)

ISO-27001-Pflichtthemen zur Wirksamkeitsmessung.

• Definierbare Kennzahlen/Metriken (z. B. SoA-Erfüllungsgrad, offene Risiken, Reaktionszeiten Vorfälle, überfällige Aufgaben, Reifegradentwicklung) mit Zielwerten und Trend.
• Strukturierte Management-Review-Vorlage (Eingaben, Ergebnisse, Beschlüsse, Verantwortliche, Termine) mit Historie.
• Wirksamkeitsbewertung von Maßnahmen; Export als Management-Report (PDF).

5. Datenmodell (Kern-Entitäten, vereinfacht)

Alle fachlichen Tabellen enthalten tenant_id, created_at, updated_at, created_by.

• Tenant(id, name, status, config)
• User(id, tenant_id, email, password_hash, name, status, mfa_secret)
• Role(id, tenant_id, key, name) / Permission / UserRole / RolePermission
• Asset(id, tenant_id, name, type, owner_id, classification_c/i/a, status, tags)
• AssetRelation(asset_id, related_asset_id, type)
• Process(id, tenant_id, name, owner_id) — BIA-Bezug
• ProcessAsset(id, tenant_id, process_id, asset_id, role = primary | secondary) — Asset-Rolle je Prozess (BIA)
• BiaEntry(id, tenant_id, process_id, rto, rpo, mtd, impact_scores, criticality)
• Threat / Vulnerability (Kataloge, teils global)
• Risk(id, tenant_id, asset_id/process_id, threat_id, likelihood, impact, score, treatment, residual_score, owner_id, status)
• RiskAsset(risk_id, asset_id) — n:m betroffene Assets je Risiko (zusätzlich zum Hauptbezug)
• RiskMeasure(risk_id, measure_id) — n:m Risiko ↔ behandelnde Maßnahmen
• Control(id, framework, ref, title, theme) — global (ISO/VDA)
• Soa(id, tenant_id, control_id, applicable, justification, status, maturity, owner_id)
• Measure/Task(id, tenant_id, title, owner_id, due_date, status, priority, links[])
• RecurringTask(id, tenant_id, type, schedule_cron, next_run, assignee)
• Policy(id, tenant_id, title, version, status, body, ack_required)
• Document/Evidence(id, tenant_id, name, storage_key, embedding[] via pgvector)
• ChatSession/ChatMessage(…, sources[], escalated_to_isb)
• Incident(id, tenant_id, title, severity, status, category, affected_assets[], timeline[])
• Audit(id, tenant_id, type, scope, planned_date) / Finding(…)
• Supplier(id, tenant_id, name, criticality, contract_ref, av_status, cert_status, cert_expiry, review_cron) / SupplierAsset(supplier_id, asset_id)
• Kpi(id, tenant_id, name, target, unit) / KpiValue(kpi_id, period, value)
• ManagementReview(id, tenant_id, date, inputs, results, decisions, owner_id)
• AuditLog(id, tenant_id, actor, action, entity, before/after, timestamp)

6. API-Design (Auszug)

REST-/tRPC-Ressourcen je Modul mit CRUD + Aktionen: /assets, /bia, /risks, /controls, /soa, /measures, /recurring-tasks, /policies, /chat, /incidents, /audits, /reports, /admin/tenants, /admin/users.

Querschnitt: GET /export/{modul} (Excel/PDF), POST /import/{modul} (Excel/CSV), Webhooks für Fristen/Eskalationen. Jede Anfrage: Auth-Guard → Mandanten-Guard → Permission-Check → Handler → AuditLog.

7. Nicht-funktionale Anforderungen

• Sicherheit: Verschlüsselung at-rest (DB/Objektspeicher) und in-transit (TLS), Argon2id-Passwörter, TOTP-2FA, Session-Härtung, CSRF-/XSS-/SQLi-Schutz, striktes RBAC + Mandanten-Isolation (RLS), vollständiges Audit-Log.
• Datenschutz (DSGVO): Auftragsverarbeitung, Löschkonzept, Datenminimierung; für Cloud-LLM: DPA mit KI-Anbieter, konfigurierbares Opt-out des Trainings, optionale Anonymisierung sensibler Felder vor KI-Aufruf.
• Performance: Listen mit Server-Pagination/Filter; Zielantwortzeit < 300 ms für Standardabfragen.
• Verfügbarkeit: Stateless App-Container (horizontal skalierbar), Backups DB + Objektspeicher, Health-/Readiness-Endpunkte.
• Barrierefreiheit & UX: WCAG-AA-orientiert, responsive, konsistente Komponenten, geringe Klicktiefe.
• i18n: Alle UI-Texte über Message-Katalog (de default, en vorbereitet).
• Nachvollziehbarkeit: Versionierung von Richtlinien, Risiken, SoA; lückenloses Änderungsprotokoll (auditfest).

8. Deployment (Docker)

docker-compose.yml mit Services: app (Next.js), worker (BullMQ), postgres (pgvector-Image), redis, minio, optional mailhog (Dev). Konfiguration über .env (DB, Redis, S3, SMTP, AI_PROVIDER, AI_API_KEY). Migrations via Prisma. Seed-Skript befüllt globale Kataloge (ISO Annex A, VDA-ISA-Struktur, Threat-/Vuln-Beispiele) und einen Demo-Mandanten.

9. UX-Leitlinien

Modern, aufgeräumt, geringe Komplexität. Konsequenter Einsatz von: geführten Wizards (BIA, Richtlinien-Assistent), Drag-and-Drop (Kanban für Maßnahmen/Aufgaben, Risiko-Heatmap, Datei-Uploads), grafischen Auswertungen (Heatmaps, Reifegrad-Radar, Fortschrittsbalken), Inline-Bearbeitung und klaren, rollenbezogenen Startseiten. Fachbegriffe mit Tooltips erklärt.

Das HTML-Mockup (docs/ISMS-Prototyp-GEFIM.html) dient als Orientierung für Navigation, Layout und Views — die Module werden fachlich darüber hinaus vervollständigt (z. B. Risiko-Verknüpfungen in Detailansichten, siehe §4).

10. Akzeptanzkriterien (Definition of Done je Modul)

• Ein Nutzer eines Mandanten sieht niemals Daten eines anderen Mandanten (durch Test nachgewiesen: RLS + Guard).
• RBAC serverseitig erzwungen; UI blendet unerlaubte Aktionen aus.
• Asset → BIA → Risiko → SoA/Maßnahme bilden eine durchgängige, verknüpfte Kette — in beide Richtungen navigierbar (Asset zeigt Risiken, Risiko zeigt Maßnahmen/Assets, Maßnahme zeigt Risiken).
• Wiederkehrende Aufgaben erzeugen automatisch Instanzen, benachrichtigen und eskalieren bei Überfälligkeit.
• Chat beantwortet Fragen mit Quellen aus Mandanten-Dokumenten und eskaliert korrekt an den ISB.
• Incident-Workflow von Meldung bis Abschluss inkl. Zeitleiste und Nachweisen.
• Exporte (SoA, Risikoregister, Audit-Report) erzeugen valide PDF/Excel.
• E2E-Tests (Playwright) für die Kernpfade grün; Audit-Log erfasst alle schreibenden Aktionen.

11. Empfohlene Umsetzungsreihenfolge (Iterationen)

Auch wenn Module gleichwertig sind, minimiert diese Reihenfolge das Risiko:

1. Fundament: Projektsetup, Docker-Compose, Auth (lokale Accounts), Mandanten-Isolation (RLS + Guard), RBAC, Audit-Log, i18n-Gerüst.
2. Kern-Fachdaten: Assets & BIA (ein Modul) → Risikoanalyse (inkl. Heatmap + Detailansicht).
3. Compliance: ISO-Annex-A-Katalog + SoA, VDA-ISA-Struktur + Mapping, Reifegrade.
4. Betrieb: Maßnahmen-Kanban, wiederkehrende Aufgaben/Scheduler, Benachrichtigungen.
5. Vorfälle: Incident-Management inkl. Meldeformular.
6. KI: RAG-Chat mit Eskalation, Richtlinien-Implementierungs-Assistent.
7. Auswertung: Dashboards, Reporting/Exporte, Audit-Management.
8. Härtung: Sicherheits-/Datenschutz-Review, Tests, Doku.

12. Lizenz-/Rechtshinweis zu Katalog-Inhalten (empfohlenes Vorgehen)

• ISO 27001:2022 Control-Titel/Referenzen (Annex A, A.5–A.8) können als Katalog abgebildet werden; der volle Normtext ist urheberrechtlich geschützt und darf nicht mitgeliefert werden. → Nur Kurzbezeichnungen + eigene Umsetzungshinweise, Volltext verweist der Kunde auf seine erworbene Norm.
• VDA-ISA 6.0 / TISAX: Der ISA-Katalog wird vom VDA/ENX bereitgestellt (ISA6 als Excel). Empfehlung: Struktur (9 Kapitel/Prüfziele) und Mapping abbilden, die konkreten Katalog-Inhalte per Import aus der offiziellen ENX-Datei einspielen (Import-Funktion für ISA6-EN.xlsx). So bleibt die Anwendung lizenzkonform und aktualisierbar.
• Mapping ISO 27001 ↔ VDA-ISA als pflegbare Tabelle vorsehen (Controls beeinflussen mehrere Prüfziele und umgekehrt).

13. Offene Punkte / spätere Erweiterungen

• SSO (OIDC/SAML, z. B. Entra ID) — Feature-Flag bereits vorgesehen.
• Self-hosted-LLM-Option je Mandant (falls Datenschutzanforderungen es verlangen).
• Meldepflichten-Assistent (NIS2/DSGVO-Fristen) im Incident-Modul.
• Mobile App / PWA für Vorfallmeldung.

---

Quellen

• VDA-ISA / TISAX Katalog v6.0: https://portal.enx.com/en-us/TISAX/downloads/
• VDA ISA 6.0 verpflichtend: https://vda-isa-berater.com/en/mandatory-vda-isa-catalog-version-6-0-for-all-those-who-order-the-tisax-assessment-now/
• VDA Information Security: https://www.vda.de/en/topics/digitization/data/information-security