craftvia/docs/wizard-uebergabe/03_Referenz/Onboarding_Wizard_Fahrplan_Detail.md

Onboarding-Wizard ISMS – Detaillierter Fahrplan & Entwickler-Handlungsanweisung

Produkt: ISMS-Applikation – Onboarding-Wizard Fokus der ersten Ausbaustufe: TISAX / VDA ISA Ziel (North Star): Assessment-Readiness – am Ende des Wizards liegt ein vorausgefüllter VDA-ISA-Katalog inkl. Reifegrad-Ersteinschätzung und Maßnahmenplan vor. Modus: Kunde bearbeitet eigenständig; ISB oder externer Berater (falls gebucht) validiert an definierten Gates. Tailoring: Template- und regelbasiert; eigene Richtlinien optional hochladbar; die mitgelieferten Vorlagen sind optional. Status: Detailausarbeitung zur Verifizierung vor der technischen Umsetzung.

---

1. Lesehinweis & Konventionen

Dieses Dokument beschreibt je Wizard-Schritt: Zweck, Ein-/Ausgaben, Verarbeitungslogik, erzeugte Objekte, kontextsensitive Umsetzungshinweise, Aufgaben-Trigger, Validierung, benötigte Entwicklungs-Ressourcen und Akzeptanzkriterien. Es ist eine fachliche Handlungsanweisung, keine technische Spezifikation – Technologiewahl, konkrete Schemata und UI-Design folgen in der Umsetzung.

Aufwands-/Ressourcengröße (T-Shirt): S = klein, M = mittel, L = groß. Bezieht sich auf den Entwicklungsaufwand des jeweiligen Bausteins, nicht auf die Kundenlaufzeit.

Rollen im Wizard

Rolle	Aufgabe
Bearbeiter (Kunde)	Durchläuft die Schritte, gibt Fakten ein, wählt/erstellt Dokumente, bewertet Controls und Risiken
Validierer (ISB intern oder externer Berater)	Prüft und gibt Module/Objekte frei; ohne Freigabe fließt Inhalt als „unbestätigt" in die Auswertung
Systemadministrator (Vorbedingung)	Richtet Mandant, Nutzer und Rollen ein – außerhalb des Wizards

---

2. Querschnittsmechaniken (gelten in allen Schritten)

Diese vier Mechaniken sind kein eigener Schritt, sondern durchziehen den gesamten Wizard und sollten früh als wiederverwendbare Bausteine gebaut werden.

2.1 Validierungs-Workflow

Jedes bearbeitbare Objekt (Modul, Richtlinie, Risiko, Control-Bewertung) trägt einen Status: offen → in Bearbeitung → zur Validierung → validiert (bzw. zurückgewiesen mit Kommentar). Nur validierte Inhalte zählen in der Assessment-Readiness-Auswertung als „bestätigt". Der Validierer erhält je Objekt Kontext, Kommentar- und Freigabefunktion. Ist kein externer Berater gebucht, übernimmt der interne ISB die Validierung. Ressourcen: Backend (Statusmodell, Rechte) M · Frontend (Review-Ansicht, Kommentare) M.

2.2 Umsetzungshinweise („So setzen Sie diese Anforderung um")

An jeder VDA-ISA-Teilanforderung (und optional an Risiken/Templates) hängt redaktioneller Hinweis-Content, der bei der Bearbeitung kontextsensitiv eingeblendet wird. Ein Hinweis umfasst typischerweise: organisatorische Umsetzungsoption, technische Umsetzungsoption, typische Nachweise, geeignete Vorlage (Verweis) und eine Ressourcenindikation (Tool/Personal/Budget/Zeit). Die Einblendung wird über Scope und Antworten gefiltert (z. B. nur AL3-relevante Hinweise). Hinweise sind Wissensinhalt, keine trackbare Aufgabe – führt ein Hinweis zu einer umzusetzenden Maßnahme, entsteht daraus eine Aufgabe (siehe 2.3). Ressourcen: Fachredaktion/ISMS-SME (Content-Pflege) L · Backend (Hinweis-Datenmodell, Filter) S · Frontend (Inline-Panel) S.

2.3 Maßnahmen → Aufgaben-Modul

Ergibt sich bei der Bearbeitung eine umzusetzende Maßnahme (z. B. „Patchmanagement-Tool einführen", „Berechtigungs-Review etablieren", „Notfallübung durchführen"), wird daraus eine Aufgabe im Aufgaben-Modul erzeugt – automatisch vorgeschlagen und vom Bearbeiter bestätigt. Trigger-Punkte: Richtlinie „später erstellen" (Schritt 4), Risikobehandlung (Schritt 6), Control-Lücke/Reifegrad < Ziel (Schritt 7), Gap-Liste (Schritt 8), Zurückweisung durch Validierer.

Aufgaben-Objekt (Felder): Titel, Beschreibung, Typ (Dokument erstellen / Nachweis liefern / technische Maßnahme / organisatorische Maßnahme), Verantwortlicher, Fälligkeit, Priorität, Status, Verknüpfung (Control / Risiko / Dokument / Asset), benötigte Ressourcen (Tool, Budget, Personal, Zeit), Herkunft (auslösender Schritt). Die Ressourcenindikation stammt aus dem Umsetzungshinweis und ist editierbar.

Beispiel: Control 5.2.3/5.2.5 unzureichend → Hinweis „technische Umsetzung: zentrales Patchmanagement" → Aufgabe „Patchmanagement-Tool auswählen und einführen", Typ technische Maßnahme, verknüpft mit 5.2.3 und 5.2.5, Ressourcen: Tool-Lizenz + IT-Personal ca. X PT, Priorität Hoch. Ressourcen: Backend (Task-Generierung, Verknüpfungen, API zum Aufgaben-Modul) M · Frontend (Vorschlag/Bestätigung, Ressourcenfelder) M. Voraussetzung: Aufgaben-Modul der App existiert bzw. bietet eine Schnittstelle.

2.4 Audit-Trail & Versionierung

Jede Eingabe, Statusänderung und Freigabe wird protokolliert (wer/wann/was). Templates, Katalog und Risikokatalog sind versioniert; Kundendokumente referenzieren die genutzte Template-Version. Ressourcen: Backend (Event-Log, Versionierung) M.

---

3. Fachliche Bausteine / Datenobjekte (Fundament)

Baustein	Inhalt	Ressourcen
Control-Katalog VDA ISA	Prüfziele, Assessment-Level, je Control die Muss-/Soll-/Zusatzanforderungen als einzeln adressierbare Teilanforderungen	SME (Datenpflege) M · Backend (Import/Modell) S
Template-Bibliothek (optional)	Richtlinien-/VA-Vorlagen mit Platzhaltern, optionalen Bausteinen und Control-Verknüpfung	SME/Content L · Backend S
Upload-Pfad eigene Dokumente	Upload + Zuordnung „welche Controls belegt dieses Dokument"	Backend S · Frontend S
Fakten-/Fragemodell	Antwortobjekte zu Organisation, IT, Dienstleistern, Prozessen; wiederverwendbar	SME (Fragebogen) M · Backend M
Risiko-Katalog	Standard- und VDA-geforderte Risiken, vordefiniert und erweiterbar; Verknüpfung zu Controls/Assets	SME L · Backend M
Regel-/Mapping-Layer	Antwort → Platzhalter, Klausel-Ein/Ausblendung, betroffene Controls/Assets/Risiken	Backend (Regel-Engine) L
Reifegrad-/Gap-Engine	Reifegrad-Ersteinschätzung + offene Punkte je Control	Backend M · SME (Logik) M

---

4. Die Schritte im Detail

Vorbedingung (außerhalb des Wizards): technisches Onboarding – Mandant, Nutzer, Rollen eingerichtet.

Schritt 1 – Scoping

• Zweck: Prüfziele, Assessment-Level (AL2/AL3), Standorte und Geltungsbereich festlegen. Dies steuert, welche Controls, Templates und Risiken im weiteren Verlauf überhaupt relevant sind.
• Eingaben: Prüfziele (Info-Sicherheit, Prototypenschutz, Datenschutz), Assessment-Level, Standort(e), organisatorischer/technischer Geltungsbereich, Ausschlüsse.
• Verarbeitung & Regeln: Aktiviert/deaktiviert Control-Set und Template-Set; z. B. Prototypenschutz nur bei entsprechendem Prüfziel, AL3 schaltet Zusatzanforderungen „sehr hoher Schutzbedarf" frei.
• Erzeugte Objekte: Scope-Objekt; gefiltertes Control-Set als Arbeitsgrundlage.
• Umsetzungshinweise: Erläuterung der Prüfziele und Level (Entscheidungshilfe AL2 vs. AL3), typische Scope-Formulierungen.
• Aufgaben-Trigger: i. d. R. keine.
• Validierung: Scope wird durch ISB/Berater bestätigt (Fundament für alles Weitere).
• Ressourcen (Entwicklung): Frontend (Scoping-UI) S · Backend (Scope-Filterlogik) M · SME (Scope-Regeln) S.
• Akzeptanzkriterien: Geänderter Scope filtert nachgelagerte Schritte korrekt; nicht relevante Controls/Templates sind ausgeblendet.

Schritt 2 – Kontextaufnahme (Gegebenheiten)

• Zweck: Die tatsächlichen Gegebenheiten der Organisation als Faktenbasis erheben, die Platzhalter befüllt und Regeln aktiviert.
• Eingaben: Geführter Fragebogen – Unternehmensdaten, Organisationsstruktur, IT-Landschaft (Systeme, Cloud, Netzwerke), eingesetzte Dienstleister, relevante Prozesse, grundlegender Schutzbedarf.
• Verarbeitung & Regeln: Antworten werden als wiederverwendbare Faktenobjekte gespeichert und mit Platzhaltern, Klauselregeln, Controls, Assets und Risiken verknüpft. Bedingte Fragen (nur anzeigen, wenn relevant).
• Erzeugte Objekte: Faktenprofil der Organisation.
• Umsetzungshinweise: Erläuterung, warum eine Angabe gebraucht wird und wie sie sich auf Dokumente/Bewertung auswirkt.
• Aufgaben-Trigger: Fehlende Grundvoraussetzung erkennbar (z. B. „kein Inventar vorhanden") → optionale Aufgabe.
• Validierung: Plausibilitätsprüfung durch ISB/Berater.
• Ressourcen (Entwicklung): Frontend (dynamischer Fragebogen) M · Backend (Faktenmodell, bedingte Logik) M · SME (Fragenkatalog) M.
• Akzeptanzkriterien: Antworten sind wiederverwendbar; eine Änderung propagiert sichtbar in abhängige Objekte.

Schritt 3 – Rollen & Verantwortlichkeiten

• Zweck: ISMS-Rollen festlegen (Geschäftsführung, ISB/DSB, IT-Verantwortung), inkl. Funktionstrennung.
• Eingaben: Personen/Funktionen je Rolle; intern/extern; Weisungs-/Berichtswege.
• Verarbeitung & Regeln: Prüft auf Funktionstrennung (z. B. ISB ≠ IT-Verantwortung); befüllt Rollen-Platzhalter in Dokumenten (Bestellungen/Ernennungen).
• Erzeugte Objekte: Rollenmodell; Dokumente wie ISB-Bestellung (aus Vorlage, optional).
• Umsetzungshinweise: Anforderungen an ISB-Qualifikation, externe vs. interne Besetzung, typische Nachweise.
• Aufgaben-Trigger: Fehlende ISB-Bestellung / fehlende Funktionstrennung → Aufgabe (organisatorische Maßnahme).
• Validierung: Freigabe des Rollenmodells.
• Ressourcen (Entwicklung): Frontend S · Backend (Rollenmodell, Regelprüfung) M · SME S.
• Akzeptanzkriterien: Funktionstrennungs-Konflikt wird erkannt und als Hinweis/Aufgabe ausgewiesen.

Schritt 4 – Richtlinien & Verfahrensanweisungen

• Zweck: Für jeden relevanten Themenbereich die belegenden Dokumente bereitstellen – flexibel in der Quelle.
• Eingaben: Je Themenbereich Auswahl einer von drei Optionen: (a) mitgelieferte Vorlage tailoren (Platzhalter aus Fakten befüllt, nicht zutreffende Klauseln ausgeblendet), (b) eigene Richtlinie hochladen und den abgedeckten Controls zuordnen, (c) als offen markieren / später erstellen.
• Verarbeitung & Regeln: (a) Template-Engine erzeugt kundenspezifisches Dokument aus Faktenprofil + Regeln; (b) Upload wird gespeichert und über Control-Mapping in die Nachweislage aufgenommen; (c) erzeugt Aufgabe.
• Erzeugte Objekte: Dokumenten-Set (generiert oder hochgeladen) mit Control-Verknüpfung und Versionsbezug.
• Umsetzungshinweise: Was die jeweilige Richtlinie mindestens enthalten muss (VDA-ISA-Bezug); Formulierungsbausteine.
• Aufgaben-Trigger: Option (c) „später erstellen" → Aufgabe Dokument erstellen; hochgeladenes Dokument ohne vollständige Control-Abdeckung → Hinweis/Aufgabe.
• Validierung: Freigabe je Dokument (Objekt-Ebene).
• Ressourcen (Entwicklung): Backend (Template-Engine, Platzhalter/Regeln, Rendering) L · Frontend (Auswahl, Editor/Vorschau, Upload) L · SME/Content (Vorlagen mit Regeln auszeichnen) L.
• Akzeptanzkriterien: Generiertes Dokument enthält keine unaufgelösten Platzhalter und keine nicht zutreffenden Klauseln; hochgeladenes Dokument ist Controls zugeordnet.

Schritt 5 – Werte-/Assetinventar (Grundstock)

• Zweck: Die für Scope und Schutzbedarf nötigen Informationswerte/Assets erfassen.
• Eingaben: Assets (Kategorie, Eigentümer, Schutzziele C/I/A, Schutzbedarf, Standort/Verknüpfung).
• Verarbeitung & Regeln: Assets werden Risiken (Schritt 6) und Controls zugeordnet; Schutzbedarf steuert die AL3-Relevanz von Zusatzanforderungen.
• Erzeugte Objekte: Assetinventar (Grundstock).
• Umsetzungshinweise: Wie man Werte identifiziert und Schutzbedarf herleitet; Beispielkategorien.
• Aufgaben-Trigger: Unvollständiges Inventar / fehlender Eigentümer → Aufgabe.
• Validierung: Freigabe des Inventars.
• Ressourcen (Entwicklung): Frontend (Inventar-CRUD, Import) M · Backend (Assetmodell, Verknüpfungen) M · SME S.
• Akzeptanzkriterien: Jedes Asset hat Eigentümer und Schutzbedarf; Verknüpfung zu Risiken/Controls möglich.

Schritt 6 – Risikomanagement

• Zweck: Risiken systematisch erfassen, bewerten und behandeln – auf Basis eines Katalogs mit Standard- und VDA-geforderten Risiken.
• Eingaben: Auswahl aus Risiko-Katalog (Standard/VDA) + eigene Ergänzungen; Bewertung (Eintrittswahrscheinlichkeit/Schadensausmaß); Behandlungsentscheidung.
• Verarbeitung & Regeln: Risiken werden mit Assets und Controls verknüpft; Bewertungsmethodik (Skalen, Akzeptanzlinie) wird angewendet; Behandlungsoptionen (reduzieren/übertragen/vermeiden/akzeptieren) mit Maßnahmenableitung.
• Erzeugte Objekte: Risikoregister; Behandlungsmaßnahmen.
• Umsetzungshinweise: Vorschlag typischer Maßnahmen je Risiko; Erläuterung der Bewertungsmethodik.
• Aufgaben-Trigger: Jede Behandlungsmaßnahme, die Umsetzung erfordert → Aufgabe (technisch/organisatorisch), verknüpft mit Risiko und Control (z. B. Risiko „Schadsoftware" → Aufgabe „Endpoint-/Patchmanagement einführen").
• Validierung: Freigabe des Risikoregisters bzw. je Risiko.
• Ressourcen (Entwicklung): Backend (Risikomodell, Bewertungslogik, Katalog) L · Frontend (Register, Matrix, Bewertung) L · SME (Risiko-Katalog + Standardmaßnahmen) L.
• Akzeptanzkriterien: VDA-geforderte Risiken sind auswählbar; jedes inakzeptable Risiko hat eine Behandlung; Maßnahmen erzeugen Aufgaben.

Schritt 7 – Control-Zuordnung & Reifegrad

• Zweck: Je relevantem VDA-ISA-Control die Umsetzung bewerten und Reifegrad einschätzen.
• Eingaben: Je Control: Verknüpfung der belegenden Dokumente/Risiken/Assets; geführte Reifegrad-Selbsteinschätzung; ggf. Kurzbeschreibung.
• Verarbeitung & Regeln: Reifegrad-/Gap-Engine schlägt auf Basis vorhandener Belege einen Reifegrad vor; offene Teilanforderungen werden markiert.
• Erzeugte Objekte: Control-Bewertung (Reifegrad, Belege, offene Punkte) – die Rohdaten des späteren VDA-ISA-Katalogs.
• Umsetzungshinweise: Pro Teilanforderung „So setzen Sie das um" (organisatorisch/technisch, Nachweise, passende Vorlage, Ressourcenbedarf).
• Aufgaben-Trigger: Reifegrad unter Ziel / offene Teilanforderung → Aufgabe (Dokument, Nachweis, technische oder organisatorische Maßnahme).
• Validierung: Freigabe der Control-Bewertung durch ISB/Berater.
• Ressourcen (Entwicklung): Backend (Scoring/Gap-Logik, Verknüpfungen) L · Frontend (Control-Ansicht, Belege, Reifegrad) L · SME (Reifegrad-Logik, Hinweis-Content) L.
• Akzeptanzkriterien: Jede relevante Teilanforderung ist adressiert; Reifegradvorschlag ist nachvollziehbar an Belege gekoppelt.

Schritt 8 – Gap- & Maßnahmenableitung

• Zweck: Offene Punkte aus Controls und Risikobehandlung zu einer priorisierten Maßnahmenliste zusammenführen.
• Eingaben: Ergebnisse aus Schritt 6 und 7; bestehende Aufgaben.
• Verarbeitung & Regeln: Deduplizierung, Priorisierung (Muss-/AL3-kritisch = hoch), Konsolidierung zu einer Gesamtsicht; Abgleich mit dem Aufgaben-Modul.
• Erzeugte Objekte: Konsolidierte Maßnahmen-/Gap-Liste (verknüpft mit Aufgaben).
• Umsetzungshinweise: Priorisierungslogik erläutert; Quick-Wins hervorgehoben.
• Aufgaben-Trigger: Jeder offene Punkt ohne bestehende Aufgabe → Aufgabe.
• Validierung: Freigabe der Maßnahmenliste.
• Ressourcen (Entwicklung): Backend (Aggregation/Dedup/Priorisierung) M · Frontend (Listenansicht, Filter) M.
• Akzeptanzkriterien: Keine Dopplungen; jeder offene Punkt hat Priorität und – wo Umsetzung nötig – eine Aufgabe.

Schritt 9 – Assessment-Readiness-Auswertung

• Zweck: Das Gesamtergebnis darstellen: vorausgefüllter VDA-ISA-Katalog, Reifegrad-Dashboard, Maßnahmenplan.
• Eingaben: Alle validierten Objekte.
• Verarbeitung & Regeln: Aggregation der Reifegrade je Kapitel/gesamt; „bestätigt vs. unbestätigt" nach Validierungsstatus; Export.
• Erzeugte Objekte: VDA-ISA-Katalog-Sicht/Export; Reifegrad-Dashboard; Maßnahmenplan.
• Umsetzungshinweise: Interpretation der Auswertung; empfohlene nächste Schritte vor dem Assessment.
• Aufgaben-Trigger: Aus offenen Hoch-Punkten ableitbar (bereits in Schritt 8 erzeugt).
• Validierung: Gesamtfreigabe/Abschluss durch ISB/Berater.
• Ressourcen (Entwicklung): Backend (Aggregation, Export) M · Frontend (Dashboard, Katalogansicht) L · SME (Auswertungslogik) M.
• Akzeptanzkriterien: Kennzahlen stimmen mit den Einzelbewertungen überein; Export ist vollständig und nachvollziehbar.

---

5. Entwicklungs-Fahrplan (Meilensteine mit Ressourcen)

Meilenstein	Inhalt	Schritte	Kern-Ressourcen	Größe
M1 Fundament	Datenmodell + Import Control-Katalog VDA ISA	–	Backend, SME	M
M2 Frage-Engine	Scoping + Kontext + Rollen	1–3	Backend, Frontend, SME	L
M3 Richtlinien-Modul	Template-Engine + Upload/Control-Mapping	4	Backend, Frontend, Content-SME	L
M4 Asset- & Risiko-Modul	Assetinventar + Risiko-Katalog + Bewertung	5–6	Backend, Frontend, SME	L
M5 Bewertungs-Engine	Control-Mapping, Reifegrad/Gap, Maßnahmen-Konsolidierung	7–8	Backend, SME, Frontend	L
M6 Ergebnis/Output	Assessment-Readiness-Auswertung + Export	9	Backend, Frontend	M
M7 Governance (querlaufend)	Validierungs-Workflow, Aufgaben-Integration, Audit-Trail, Versionierung, Umsetzungshinweise	alle	Backend, Frontend, SME	L

Kürzester Pfad zur Assessment-Readiness: M1 → M2 → M3 → M4 → M5 → M6. M7 wird parallel eingezogen (Validierung, Aufgaben und Hinweise sollten nicht nachträglich „angeflanscht" werden). Nachweis-Upload ist bewusst spätere Iteration.

---

6. Ressourcen-Gesamtübersicht (Rollen im Entwicklungsprojekt)

Rolle	Beitrag	Auslastung (grob)
ISMS/TISAX-SME (Fachredaktion)	Control-Katalog, Templates mit Regeln, Risiko-Katalog, Umsetzungshinweise, Reifegrad-/Bewertungslogik	hoch, durchgehend – der inhaltliche Flaschenhals
Backend-Entwicklung	Datenmodell, Regel-/Mapping-Engine, Scoring, Task-Integration, API, Audit-Trail	hoch
Frontend-Entwicklung	Wizard-Flow, dynamische Formulare, Editor/Vorschau, Dashboards	hoch
Content-/Template-Engineering	Vorlagen mit Platzhaltern und Regel-Tags auszeichnen	mittel, in M3 konzentriert
UX/Design	geführter Flow, Statusführung, Hinweis-Panels	mittel
QA/Test	Regel-/Scoring-Korrektheit, Dokumentgenerierung, Freigabelogik	mittel–hoch

Wichtig: Der größte, oft unterschätzte Aufwand liegt nicht in der Software, sondern im Fachcontent (Control-Daten, regelfähige Vorlagen, Risiko-Katalog, Umsetzungshinweise). Dieser sollte parallel und früh durch die Beratung erstellt werden, sonst wird er zum kritischen Pfad.

---

7. Offene Entscheidungspunkte (vor der technischen Spezifikation zu klären)

1. Upload eigener Richtlinien: nur Control-Zuordnung, oder zusätzlich ein automatischer Abgleich Dokumentinhalt ↔ Anforderungen (Gap-Check)?
2. Risiko-Bewertungsmethodik: fest vorgegeben oder mandantenspezifisch konfigurierbar (Skalen, Akzeptanzlinie)?
3. Versionierung von Katalog/Templates/Risiken: wie werden laufende Kundeninstanzen bei Updates nachgezogen (automatisch, mit Diff, manuell)?
4. Validierungsgranularität: pro Modul, zusätzlich pro Einzelobjekt (einzelne Richtlinie/Risiko/Control)?
5. Aufgaben-Modul: existiert bereits mit passender Schnittstelle, oder muss die Task-Erzeugung mitgeplant werden?
6. Reifegrad-Vorschlag: rein regelbasiert aus Belegen, oder als Empfehlung mit Pflicht zur Bestätigung durch den Bearbeiter?

---

8. Nächster Schritt

Nach Verifizierung dieses Fahrplans: technische Feinspezifikation je Modul (Datenschemata, Regel-Syntax, API-Verträge, UI-Wireframes, Akzeptanztests) – vorgeschlagene Reihenfolge entlang der Meilensteine M1–M7.