craftvia/docs/KONZEPT-framework-iso27001.md

KONZEPT: Mehr-Framework-Fähigkeit — ISO 27001 neben TISAX (pro Mandant wählbar)

Stand: 2026-08-21 · Zielgruppe: mehrköpfiges Entwicklerteam + PM · Status: Entwurf zur Abnahme

Nachtrag 2026-08-21 — D4 und Lane 2 sind entschieden und umgesetzt: Nicht zwei Seed-Pakete, sondern ein Dokumentensatz mit zwei Framework-Mappings (Variante A). Umsetzung und Begründung: docs/FRAMEWORK-MAPPING-ISO27001.md. Die übrigen Lanes bleiben unverändert gültig.

Ziel: Kunden sollen pro Mandant ISO 27001 und/oder TISAX wählen können. Je Framework gibt es u. a. ein eigenes Vorlagenpaket, einen eigenen Control-Katalog und eine eigene Audit-/Readiness-Logik. Heute ist das Tool durchgängig implizit auf VDA-ISA 2027 / TISAX verdrahtet.

---

1. Ausgangslage (Ist-Analyse, belegt)

Das Fachmodell kennt kein „Framework/Standard" pro Mandant. Alles ist implizit VDA-ISA/TISAX:

• Kein Framework-Feld: Tenant (prisma/schema.prisma:31) hat nur sector + generisches config Json; TenantSettings (:52) hat als einzigen Standard-Anker tisaxLevel (:70, „AL2|AL3"). ISO 27001 erscheint nur als Marketing-Text (src/lib/brand.ts:57) und in einem Kommentar (src/server/actions/tenant-users.ts:197).
• Control-Katalog liegt als String-ID vor (kein Enum): ControlAssessment.control (:967, z. B. „1.3.1"/„5.3.4-KI", Werte 0–3), ControlImplementation.reqId (:988), ControlDescription (:1217, „VDA-ISA-Spalte 4"). Titel/IDs kommen aus VDA-ISA (src/lib/control-titles.ts:1). Domain-Enum (:1029) enthält TISAX-only PROTOTYPE.
• Ein Vorlagenpaket verdrahtet: Parser prisma/import-policies.ts (Codes L00/R../VA-, :115), globale Ablage PolicyTemplateVersion (:1637, ohne Framework-Dimension), Auflösung prisma/template-store.ts (resolvePackageForTenant wählt nur nach Locale die eine neueste PUBLISHED-Version, :147), Sync-Skript scripts/sync-policy-templates.ts:20 (fest seed/isms-vorlagenpaket-v2 de/en, meta.standard:"VDA ISA 2027", version:"2.1").
• Readiness/Reifegrad ist TISAX: Reifegrad 0–3 (src/lib/maturity.ts:11), Zielgrad aus AL2/AL3 + Schutzbedarf (src/server/assessment-level.ts), Anforderungsschema MUSS/SOLL/HOCH/SEHR-HOCH + Prüfziele IS/Prototyp(8.)/Datenschutz(9.) (src/lib/scope-filter.ts, src/lib/export/vda-isa.ts:9). Die reinen Rechen-Engines src/lib/readiness.ts und src/lib/gap-consolidation.ts sind numerisch standard-agnostisch.
• SoA existiert als Modul-Key soa (src/lib/modules.ts:19), ist faktisch aber ein VDA-ISA-Reifegrad-Assessment (src/server/actions/soa.ts, Werte 0–3), nicht die ISO-typische Applicability-Erklärung (anwendbar/ausgeschlossen + Begründung je Annex-A-Control).
• Provisionierung: provisionTenant (src/server/provision.ts:53) ist die zentrale Stelle — schreibt tisaxLevel, aktiviert alle Module, importiert das eine Paket, setzt TISAX-Schutzbedarf-Flags. ProvisionOpts kennt kein framework.

Bereits standard-agnostisch (wiederverwendbar): Multi-Tenancy/RLS, Modul-Toggle (TenantModule), Vorlagen-Mechanik (Parser-Struktur, nicht-destruktiver reconcilePackage, DB-Versionsablage, Locale-Fallback), Control-Speicherung als String-ID, Onboarding-Registry/Progress, die Rechen-Engines readiness/gap.

Hart an TISAX gekoppelt (abstrahieren/duplizieren): AL2/AL3-Schutzbedarf + Flags, Reifegrad 0–3 + C5-Belegtabelle, MUSS/SOLL-Schema + Prüfziele 8./9., der eine Vorlagenpaket-Pfad + single-published-Auflösung, VDA-ISA-Exporte/Labels, Control-Titel, Domain.PROTOTYPE, die SoA-Semantik, zahlreiche i18n-Labels „TISAX"/„VDA-ISA".

---

2. Zielbild

Ein Framework als First-Class-Dimension: Mandant wählt ein oder mehrere Frameworks (ISO_27001, TISAX). Je Framework werden Vorlagenpaket, Control-Katalog, Scope-/Assessment-Modell, Readiness/SoA-Sicht und Export framework-spezifisch aufgelöst — über eine Strategie-Schicht, damit die generische Mechanik (Tenancy, Vorlagen-Import, Wizard-Shell, Rechen-Engines) unverändert bleibt.

Leitprinzipien:

• Additiv / Expand-Contract: bestehende (Test-)Mandanten laufen unverändert als TISAX weiter; neue Spalten/Tabellen additiv, keine Datenmigration von Inhalten (nur Testdaten).
• TISAX-Verhalten bleibt bit-genau erhalten (Regressionsschutz) — ISO wird daneben gebaut, nicht statt.
• Ein Mandant kann beide Frameworks führen (n:m) — geteilte Belege/Policies, aber getrennte Katalog-/SoA-Sichten.
• Feature-Flag: ISO bleibt hinter einem Schalter, bis Katalog + Readiness + SoA abgenommen sind.

---

3. Entscheidungen (D) — vom Team/PO zu bestätigen

#	Entscheidung	Empfehlung	Begründung
D1	Framework-Kardinalität	n:m (Mandant kann ISO und TISAX) via eigener Tabelle TenantFramework	Nutzeranforderung „oder/und"; erlaubt per-Framework-Attribute (z. B. TISAX-Level, ISO-Zertifizierungsziel).
D2	tisaxLevel	bleibt vorerst auf TenantSettings, wird als TISAX-scoped dokumentiert (nur relevant, wenn TISAX aktiv); optional später in TenantFramework.config verschieben	Minimiert Migration + die ~356 dbForTenant-Aufrufstellen; kein Umbau bestehender Reads.
D3	Control-Speicherung	String-ID beibehalten, Framework als zusätzliche Dimension (kein Enum-Umbau)	ControlAssessment.control etc. nehmen ISO-Annex-A-IDs (A.5.1 …) ohne Schema-Bruch auf.
D4	Vorlagenpaket	zweites Seed-Paket → entschieden 2026-08-21: ein Dokumentensatz, zwei Mappings (mapping.json + mapping-iso.json in seed/isms-vorlagenpaket-v2). framework-Dimension auf PolicyTemplateVersion bleibt nötig (+ Unique (framework, version)).	Gleiche Dokument-Codes können in einem Mandanten nicht zweimal existieren (@@unique([tenantId, code])); der Umsetzungstext ist ohnehin normunabhängig. Siehe FRAMEWORK-MAPPING-ISO27001.md.
D5	Assessment-Modell	Strategie-Interface je Framework (Scope/Reifegrad/Ziel/SoA), TISAX = heutige 0–3/AL-Logik, ISO = SoA-Applicability + Umsetzungsstatus	ISO kennt kein AL2/AL3 und keine VDA-ISA-Reifegrade; saubere Trennung ohne TISAX-Regression.
D6	ISO-SoA	echte Statement of Applicability (Annex-A-Liste, anwendbar/ausgeschlossen + Begründung, Verknüpfung Policy/Evidence) — neu für ISO; TISAX behält sein Reifegrad-Assessment	ISO-27001-Kernartefakt fehlt heute fachlich.
D7	Rollout	Feature-Flag „ISO" + erst Test-Instanz; TISAX unverändert	Risikoarme Einführung; TISAX-Kunden unberührt.
D8	Katalog-Grundlage ISO	Annex A (ISO/IEC 27001:2022, 93 Controls, 4 Themen) + Klauseln 4–10 als Managementsystem-Anforderungen	Aktueller Normstand; 2022er Struktur.

---

4. Zielarchitektur

4.1 Datenmodell (additiv)

• enum Framework { ISO_27001, TISAX }.
• model TenantFramework (n:m): tenantId, framework, isPrimary Boolean, config Json (per-Framework-Attribute, z. B. { tisaxLevel: "AL3" } bzw. { certScope, certBodyTarget }), Unique (tenantId, framework). → in TENANT_MODELS (RLS) aufnehmen.
• PolicyTemplateVersion: neue Spalte framework Framework; Unique (framework, version) statt nur version; Default-Backfill TISAX.
• PolicyPackageState (Mandanten-Merker, schema:1612): um framework erweitern (je Framework eine importierte Version).
• ISO-SoA (neu): model SoaEntry { tenantId, framework=ISO_27001, control (A.x.y), applicable Boolean, justification String, implementationStatus enum, linkedPolicyCode?, linkedEvidenceId? } — RLS-scoped.
• Domain-Enum: ISO-Themen ergänzen bzw. PROTOTYPE als TISAX-only markieren; ISO-Controls mappen auf die 4 Annex-A-Themen (Organizational/People/Physical/Technological) → entweder neue Enum-Werte oder eine framework-abhängige Domain-Auflösung.

4.2 Strategie-Schicht (Kernstück)

Ein FrameworkStrategy-Interface kapselt alle TISAX-spezifischen Annahmen; je Framework eine Implementierung:

interface FrameworkStrategy {
  key: Framework
  resolvePackage(locale): PublishedPackage        // template-store, framework-parametrisiert
  loadCatalog(): { controls, titles, scope }      // c1/c5/mapping bzw. Annex-A/Klauseln
  scopeFilter(settings): ControlRow[]             // TISAX: AL/Prüfziel · ISO: Applicability
  targetFor(control, settings): AssessmentTarget  // TISAX: Reifegrad 0–3 · ISO: Umsetzungsstatus/SoA
  readinessView(rows): ReadinessSummary           // nutzt generische readiness/gap-Engines
  export(): ExportArtifact                        // TISAX: VDA-ISA · ISO: SoA + Annex-A-Gap
  wizardSteps(): StepKey[]                         // framework-abhängige Sichtbarkeit/Inhalte
}

Bestehende Dateien werden hinter diese Schnittstelle gezogen: assessment-level.ts, maturity.ts, scope-filter.ts, control-titles.ts, export/vda-isa*.ts → TisaxStrategy. Die generischen Engines readiness.ts/gap-consolidation.ts bleiben und werden von beiden Strategien gefüttert.

4.3 Auflösung zur Laufzeit

• template-store.ts: resolvePackageForTenant(tenant, framework, locale) — wählt PUBLISHED-Version je (framework, locale).
• provisionTenant: ProvisionOpts.frameworks: Framework[] → schreibt TenantFramework-Zeilen, importiert je Framework das passende Paket + Katalog, setzt nur bei TISAX die AL-Flags.
• UI/Server lösen die aktive Framework-Sicht über die Mandanten-TenantFramework + eine aktive Auswahl (bei Mehr-Framework: Umschalter, analog Mandantenwahl).

---

5. Workstreams / Lanes für das Team

Fünf Lanes + PM. Abhängigkeiten in Klammern.

Lane 1 — Framework-Kern (Datenmodell, Provision, Auflösung) (Fundament, zuerst)

• Framework-Enum, TenantFramework-Tabelle (+ RLS/TENANT_MODELS), PolicyTemplateVersion.framework (+ Unique), PolicyPackageState.framework — additive Expand-Migrationen + Backfill bestehender Daten auf TISAX.
• ProvisionOpts.frameworks + framework-abhängige Paket-/Katalog-Auflösung in provision.ts.
• template-store.ts framework-parametrisieren.
• DoD: bestehende Mandanten laufen unverändert (framework=TISAX), neuer Mandant kann mit frameworks:[ISO_27001] oder [TISAX] oder beiden provisioniert werden; Gate grün.

Lane 2 — ISO-Mapping & -Katalog (inhaltlicher Teil erledigt; Rest braucht L1)

• ✅ erledigt (2026-08-21): mapping-iso.json (27 Klauseln + 93 Annex-A-Controls) auf der bestehenden Bibliothek; 19 ISO-only-Abschnitte ergänzt; Sichtbarkeit über FLAG_FW_ISO27001/FLAG_FW_TISAX; SoA-Gerüst mit den Pflichtangaben aus 6.1.3 d); _verify_iso.py grün.
• ⬜ ISO-control-titles, ISO-Scope-/Control-Kataloge (Pendants zu c1-scope.json/c5-controls.json).
• ⬜ parsePackageFiles/sync-policy-templates.ts über Frameworks × Sprachen iterieren — heute ist mapping.json fest verdrahtet, mapping-iso.json wird noch nicht gelesen.
• ✅ erledigt: Englische Fassung isms-vorlagenpaket-v2-en nachgezogen (eigene Texte, --lang en).
• DoD: ISO-Mapping importiert als eigene PolicyTemplateVersion(framework=ISO_27001); ein ISO-Mandant erhält Annex-A-Controls und sieht die ISO-Anforderungssicht.

Lane 3 — Assessment-/Readiness-Abstraktion (braucht L1; parallel zu L2)

• FrameworkStrategy-Interface; heutige TISAX-Logik als TisaxStrategy extrahieren (verhaltensgleich!).
• IsoStrategy: Scope = Applicability; Ziel = Umsetzungsstatus (statt Reifegrad 0–3); Readiness/Gap über die bestehenden generischen Engines.
• readiness.ts/gap-consolidation.ts framework-parametrisiert füttern; keine TISAX-Regression.
• DoD: TISAX-Readiness identisch zu heute (Snapshot-Test); ISO liefert eine erste Readiness-/Gap-Sicht auf Annex-A-Basis.

Lane 4 — ISO-SoA + Exporte (braucht L2+L3)

• Echte SoA-Sicht (SoaEntry): Annex-A-Liste, anwendbar/ausgeschlossen + Begründung, Verknüpfung Policy/Evidence, Umsetzungsstatus; Modul-Key soa beherbergt beide Sichten (TISAX-Reifegrad bleibt).
• ISO-Export: SoA-Dokument + Annex-A-Gap-Report; VDA-ISA-Export bleibt TISAX-only.
• DoD: ISO-Mandant kann eine vollständige SoA pflegen und exportieren.

Lane 5 — Wizard, Settings/Admin & i18n (braucht L1; UI-Feinschliff am Ende)

• Framework-Auswahl in Admin (Mandant anlegen) + /settings; setTenantTisaxLevel → TISAX-scoped, ISO-Zertifizierungsziel analog.
• Onboarding-Registry framework-aware (getVisibleSteps guard je Framework): TISAX behält Scope/AL/Prüfziel + Controls-Reifegrad; ISO ersetzt AL-Schritt durch Applicability/SoA-Schritt.
• i18n: framework-neutrale Labels + per-Framework-Overrides; „TISAX/VDA-ISA"-Strings entkoppeln (messages/de.json/en.json, settings/page.tsx, audit-readiness/*, admin/page.tsx).
• DoD: Kunde wählt im Admin ISO und/oder TISAX; der Wizard zeigt die passenden Schritte; keine „TISAX"-Labels bei reinen ISO-Mandanten.

PM: Reihenfolge L1 → (L2 ∥ L3) → L4 → L5; Abnahme je Lane; Regressions-Gate für TISAX (Snapshot der heutigen Readiness/Exporte) als Pflicht vor jedem Merge.

---

6. Migration & Rollout

• Expand: additive Migrationen (Enum, TenantFramework, Spalten); Backfill: für jeden bestehenden Mandanten TenantFramework(framework=TISAX, isPrimary=true); PolicyTemplateVersion.framework=TISAX.
• Feature-Flag „ISO 27001" (Plattform-Setting) gated Admin-Auswahl + Provisionierung, bis L2–L4 abgenommen.
• Keine Inhaltsmigration (nur Testdaten); neue ISO-Mandanten frisch provisioniert.
• Contract (später): ungenutzte TISAX-only-Felder erst nach stabilem Mehr-Framework-Betrieb aufräumen (z. B. tisaxLevel → TenantFramework.config).

7. Risiken & Gegenmaßnahmen

Risiko	Gegenmaßnahme
TISAX-Regression durch Refactoring	TisaxStrategy verhaltensgleich extrahieren; Snapshot-Tests der heutigen Readiness/Exporte als Merge-Gate.
ISO-Katalog-Qualität (Annex-A ↔ Policies)	Fachliches Mapping-Review (ISMS-Experte) vor L4; mapping.json als Single Source.
SoA-Semantik ist fachlich neu	Eigene Lane (L4) mit klarer Definition applicable/exclusion + Begründungspflicht.
Mehr-Framework-Komplexität in UI	Aktive-Framework-Umschalter analog Mandantenwahl; getrennte Katalog-Sichten.
Domain.PROTOTYPE/AL nur TISAX	Framework-abhängige Domain-/Scope-Auflösung; ISO ignoriert AL/Prototyp.
i18n-Wildwuchs „TISAX"	Zentrale framework-neutrale Keys + Overrides; Lint auf verbleibende Hardcodes.

8. Grobe Aufwandsschätzung

Lane	Aufwand (PT, grob)
L1 Framework-Kern	4–6
L2 ISO-Paket & Katalog (inkl. fachliches Mapping)	8–12
L3 Assessment-Abstraktion	5–8
L4 ISO-SoA + Exporte	5–8
L5 Wizard/Settings/i18n	4–6
PM/Fachreview	durchgehend
Summe	~26–40 PT, L2/L3 parallelisierbar

9. Offene Punkte (vom PO/Fachexperten zu klären)

• Umfang ISO-Vorlagenpaket: nur Annex-A-Controls oder auch Managementsystem-Klauseln 4–10 als geführte Artefakte? (Empfehlung: beides.)
• Wie stark sollen ISO- und TISAX-Sicht bei Doppel-Framework Belege/Policies teilen? → entschieden: ein gemeinsames Policy-Set, zwei Mappings (Variante A, 2026-08-21).
• ISO-Reifegrad optional zusätzlich zur Applicability (manche Kunden wollen Reifegrade auch unter ISO)?
• Zielformat ISO-Exporte (SoA-Dokument als Word/PDF/XLSX; Annex-A-Gap als XLSX).