# 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.