craftvia/docs/FEINDESIGN-framework-assessment.md

Feindesign B1 — Assessment und Readiness für zwei Frameworks

Stand: 2026-08-27 · Branch: feature/iso27001-framework-mapping · Status: Entwurf zur Abnahme

Ausgangslage: AP1–AP5 sind umgesetzt. Ein ISO-Mandant hat Dokumente, SoA-Modell, Kennzahlen, Managementbewertung und Korrekturmaßnahmen. Was fehlt, ist die Bewertungs- und Readiness-Sicht: maturity.ts, scope-filter.ts, assessment-level.ts und readiness.ts kennen kein Framework und rechnen durchgängig VDA ISA — AL2/AL3, Prüfziele, Reifegrad 0–3, MUSS/SOLL.

Belegter Bruch: soa-context.ts:151 und export-context.ts:49 lesen controlAssessment. Keine einzige Stelle liest soaEntry. Das in AP3 gebaute SoA-Modul ist von der Auswertung abgekoppelt — die Daten liegen da, die Readiness greift nicht darauf zu.

Grundlage: docs/KONZEPT-framework-iso27001.md (Lane 3), docs/FRAMEWORK-MAPPING-ISO27001.md, docs/UEBERGABE-framework-iso27001.md.

---

1. Leitentscheidung: die Belegbasis liegt unterhalb der Framework-Strategie

Es werden nicht zwei Engines gebaut. Der Belegstatus eines Controls — ist die zuständige Richtlinie freigegeben, existiert das Verfahren, hängt ein Asset dran, gibt es einen Wirksamkeitsnachweis — ist eine Tatsache über die Organisation, keine Frage der Norm. Ob R08 freigegeben ist, ändert sich nicht dadurch, ob ISO oder VDA ISA danach fragt.

Würde man die Belegbasis mitparallelisieren, entstünden zwei Bewertungen derselben Realität, die auseinanderlaufen können. Im Audit steht dann „Berechtigungsvergabe: TISAX Reifegrad 3" neben „ISO: teilweise umgesetzt" — ein Widerspruch über denselben Sachverhalt.

Regel: eine Belegbasis, zwei Bewertungen.

Schicht 3  Sichten        /soa · /audit-readiness · Exporte · Wizard-Schritte    → Reiter je Framework
Schicht 2  Strategie      Scope · Zielwert · Bewertung · Vokabular               → je Framework
Schicht 1  Belegbasis     loadEvidenceResolver → ControlEvidence                 → GETEILT
Schicht 0  Fachdaten      PolicyDocument · Evidence · Asset · Risk · Measure     → GETEILT

Das ist derselbe Schnitt wie bei den Richtlinien: ein Umsetzungstext, zwei Anforderungssichten.

---

2. Was generalisiert wird (Schicht 1)

ControlEvidence (src/lib/maturity.ts:54) ist bereits framework-neutral — Richtlinienstatus, Verfahrensstatus, Asset-/Risiko-Verknüpfung, operativer Wirksamkeitsnachweis. Nur der Eingabetyp des Resolvers ist TISAX-spezifisch.

Änderung: C5ControlSpec (maturity.ts:16) wird auf ein neutrales ControlSpec reduziert:

export interface ControlSpec {
  control: string;        // "4.1.2" | "A.8.5"
  title: string;
  policy: string[];       // ["R08"]
  verfahren: string[];    // ["VA-03"]
  needsAsset: boolean;
  needsRisk: boolean;
}
// C5ControlSpec extends ControlSpec { target: number }  — TISAX-Zusatzfeld bleibt dort

loadEvidenceResolver(db, completeControls) nimmt künftig ControlSpec. Für TISAX ändert sich nichts — C5ControlSpec erfüllt das Interface.

ISO-Specs kommen aus dem Mapping, nicht von Hand

mapping-iso.json trägt je Anforderung bereits policy (R-Code) und verfahren (VA-Codes). Daraus lässt sich der ISO-ControlSpec erzeugen. needsAsset/needsRisk werden über den vorhandenen Crosswalk ISO_TO_ISA (src/lib/iso-isa-crosswalk.ts, 87 der 120) vom ISA-Spec geerbt; für die 33 ISO-eigenen Abschnitte werden sie explizit gesetzt — sinnvoll nur bei A.5.9 (needsAsset) sowie 6.1.2/6.1.3/8.2/8.3 (needsRisk).

Umsetzung: _generate_iso.py erzeugt zusätzlich src/lib/control-specs-iso.ts — analog zu control-titles-iso.ts und iso-isa-crosswalk.ts. Damit bleibt das Mapping die einzige Quelle und niemand pflegt eine zweite Liste.

---

3. Die Strategie-Schnittstelle (Schicht 2)

export type FrameworkKey = "TISAX" | "ISO_27001";

/** Bewertung eines Controls — je Framework ein eigener Typ, nie gemischt. */
export type Verdict =
  | { kind: "maturity"; suggested: 0 | 1 | 2 | 3; confirmed: number | null; target: 2 | 3 }
  | { kind: "status"; applicable: boolean; suggested: ImplStatus; confirmed: ImplStatus | null };

export type ImplStatus = "umgesetzt" | "teilweise" | "geplant";

export interface AssessmentRow {
  control: string;
  title: string;
  spec: ControlSpec;
  evidence: ControlEvidence;   // aus Schicht 1, identisch für beide Frameworks
  verdict: Verdict;            // je Framework interpretiert
  gaps: OpenPoint[];
}

export interface FrameworkStrategy {
  key: FrameworkKey;
  /** Anzeigename für Reiter und Berichte. */
  label: string;                                   // "TISAX / VDA ISA 2027" | "ISO/IEC 27001:2022"
  /** Datei im Vorlagenpaket. */
  mappingFile: string;                             // "mapping.json" | "mapping-iso.json"
  /** Controls im Geltungsbereich — TISAX: AL + Prüfziele · ISO: Anwendbarkeit aus der SoA. */
  controlsInScope(db: TenantDb): Promise<ControlSpec[]>;
  /** Bewertung eines Controls aus geteiltem Beleg + framework-eigener Regel. */
  evaluate(spec: ControlSpec, ev: ControlEvidence, ctx: EvalContext): Verdict;
  /** Offene Punkte, die aus der Lücke zum Zielwert folgen. */
  gaps(spec: ControlSpec, ev: ControlEvidence, v: Verdict): OpenPoint[];
  /** Kennzahl und Textband — framework-eigenes Vokabular, kein gemeinsamer Nenner. */
  summarise(rows: AssessmentRow[]): ReadinessSummary;
}

buildControlRows (soa-context.ts:146) wird zu buildAssessment(db, tenantId, framework) und delegiert an die Strategie. Die Belegauflösung bleibt, wo sie ist.

TisaxStrategy — verhaltensgleich extrahieren

Reine Umverdrahtung, kein neues Verhalten: loadScopeInput + controlsInScope → controlsInScope, suggestMaturity + targetMaturity → evaluate, openPoints → gaps, computeReadiness → summarise. Regressionsschutz: Snapshot-Test gegen die heutige Ausgabe (siehe §7).

IsoStrategy — neu

Aspekt	Regel
Scope	SoaEntry.applicable = true. Kein AL, keine Prüfziele. Klauseln 4–10 sind immer im Scope (nicht Gegenstand der Anwendbarkeit).
Zielwert	implementationStatus = "umgesetzt" für jedes anwendbare Control. Keine Stufung.
Vorschlag	aus ControlEvidence: Richtlinie und Verfahren validiert + geforderte Verknüpfungen vorhanden → umgesetzt; teilweise belegt → teilweise; sonst geplant.
Bestätigung	SoaEntry.implementationStatus ist der bestätigte Wert; der Vorschlag überschreibt ihn nie (Muster wie ControlAssessment.suggested / confirmedValue).
Lücken	fehlende Begründung, fehlender Nachweis, Status ≠ „umgesetzt" bei anwendbarem Control.

---

4. Vorbelegung bei Doppel-Framework — gegen Doppelerfassung

Führt ein Mandant beide Normen, darf der ISB nicht zweimal dasselbe beantworten. Über ISO_TO_ISA ist bekannt, welches ISA-Control denselben Bibliotheksabschnitt trägt.

Regel: Ist das zugehörige ISA-Control bestätigt und erreicht seinen Zielreifegrad, schlägt die ISO-Sicht umgesetzt vor — mit Verweis auf denselben Nachweis. Der ISB bestätigt, das System setzt nichts automatisch.

Für die 33 ISO-Anforderungen ohne ISA-Gegenstück (Managementsystem-Klauseln, Clear Desk, DLP, Kapazität, Zeitsynchronisation …) gibt es keine Vorbelegung — sie werden regulär bewertet. Das ist zugleich die ehrliche Aussage an den Kunden: das ist die Delta-Arbeit, die ISO gegenüber TISAX zusätzlich verlangt. Diese Liste ist ein verkaufbares Ergebnis für sich.

---

5. Sichten und Reiter (Schicht 3)

Bereich	Reiter ISO / TISAX	Begründung
Controls- / SoA-Sicht (/soa)	ja	zwei Kataloge, zwei Zielsysteme
Readiness (/audit-readiness)	ja	je Norm eine eigene Aussage und ein eigenes Vokabular
Exporte	ja	VDA-ISA-Export bleibt TISAX; SoA und Annex-A-Gap sind ISO
Richtlinien (/policies)	nein	ein Dokumentensatz; Parallelanzeige im Dokument ist gebaut
Nachweise	nein	ein Beleg belegt eine Tatsache, unabhängig von der fragenden Norm
Assets, Risiken, Vorfälle, Lieferanten, Aufgaben	nein	framework-neutral

Reiter-Verhalten: ein aktives Framework → kein Reiter, direkte Anzeige. Zwei aktive Frameworks → Reiter, Vorauswahl TenantFramework.isPrimary. Die Auswahl gehört in die URL (?fw=iso), damit Deep-Links und Berichte reproduzierbar sind.

Harte Regel: keine gemischte Gesamtzahl. Ein „Erfüllungsgrad 87 %" über beide Normen ist fachlich sinnlos — ein Reifegrad 0–3 und ein Umsetzungsstatus lassen sich nicht mitteln. Je Norm eine Kennzahl, immer getrennt ausgewiesen.

---

6. Vokabular

REIFEGRAD_BANDS (readiness.ts:16) ist TISAX-Sprache („Assessment-reif", „AL-Ziel"). Für ISO gehören eigene Bänder auf Basis des Umsetzungsgrads — Vorschlag:

Anteil „umgesetzt"	Band	Aussage
< 50 %	Aufbau	wesentliche Maßnahmen noch offen
50–79 %	In Umsetzung	Struktur steht, Nachweise fehlen
80–99 %	Zertifizierungsnah	wenige offene Punkte, Wirksamkeitsnachweise ergänzen
100 %	Zertifizierungsreif	alle anwendbaren Controls umgesetzt und belegt

Ein ISO-Auditbericht darf nicht mit „Reifegrad 2,4" argumentieren. Der Nachweis lautet „umgesetzt, hier ist der Beleg". Der Reifegrad bleibt unter ISO ein optionales Beratungsinstrument — sichtbar als Zusatzspalte, nie als Erfüllungsaussage (Entscheidung aus dem Fachgespräch, Variante 3).

---

7. Regressionsschutz

Die Extraktion der TisaxStrategy ist der riskanteste Teil. Absicherung vor dem Umbau:

1. Snapshot erzeugen: buildControlRows für den Demo-Mandanten (321 Anforderungen, 45 Controls) als JSON festhalten — Reifegradvorschlag, Zielwert, Belegstatus und offene Punkte je Control.
2. Nach dem Umbau vergleichen: buildAssessment(db, tenantId, "TISAX") muss denselben Snapshot liefern. Abweichung = Regression, kein „ist besser geworden".
3. Als scripts/test-framework-assessment.ts in der Hausform der übrigen test-*.ts ablegen.

Ergänzend unverändert gültig: _verify.py, _verify_iso.py --lang de|en, _render_diff.py HEAD, test-framework-dryrun.ts.

---

7a. Priorisierung nach Kundenlage (Nachtrag 2026-08-27)

Ist-Lage: Die Mehrzahl der Mandanten führt TISAX, ein Mandant ISO, keiner beide.

Daraus folgt zweierlei:

1. Das Regressionsrisiko dominiert. Der riskanteste Teil ist nicht die ISO-Logik, sondern die verhaltensgleiche Extraktion der TisaxStrategy — sie betrifft alle Bestandsmandanten. Schritt 1 (Snapshot) ist damit nicht Kür, sondern die wichtigste Einzelmaßnahme des ganzen Pakets.
2. Zwei Themen lassen sich zurückstellen — beide betreffen ausschließlich den Doppel-Mandanten, den es heute nicht gibt:

Zurückgestellt	Was entfällt vorerst	Wieder aufnehmen, wenn
Schritt 7 — Vorbelegung über ISO_TO_ISA	Übernahmevorschlag aus dem jeweils anderen Framework	ein Mandant beide Normen führt
Schritt 8b — Reiter-UI	Umschalter in /soa und /audit-readiness; bei einem aktiven Framework wird direkt angezeigt	ein Mandant beide Normen führt

Was dabei nicht zurückgestellt werden darf: die Strategie-Schnittstelle und der Framework-Parameter in buildAssessment. Beide kosten jetzt fast nichts und sind später teuer nachzurüsten, weil sonst 7 Aufrufstellen erneut angefasst werden müssen. Die Architektur bleibt zweigleisig, nur die Oberfläche zeigt vorerst ein Gleis.

Erwartete Wirkung auf den Aufwand: 5–8 PT → 4–6 PT.

---

8. Arbeitsschritte

#	Schritt	Ergebnis
1	Snapshot-Test der heutigen TISAX-Ausgabe	Regressionsnetz steht, vor jedem Umbau
2	ControlSpec einführen, loadEvidenceResolver darauf umstellen	Belegbasis framework-neutral, TISAX unverändert
3	_generate_iso.py erzeugt control-specs-iso.ts	ISO-Specs aus dem Mapping, keine Zweitpflege
4	FrameworkStrategy + TisaxStrategy (reine Extraktion)	Snapshot grün
5	IsoStrategy (Scope aus SoA, Status statt Reifegrad)	ISO-Bewertung rechnet
6	buildAssessment(db, tenantId, framework) ersetzt buildControlRows	7 Dateien rufen es direkt, 13 hängen an der Assessment-Logik insgesamt
7	Vorbelegung über ISO_TO_ISA	zurückgestellt — betrifft nur Doppel-Mandanten (§7a)
8a	ISO-Readiness-Bänder und framework-richtige Beschriftung	ISO-Mandant sieht ISO-Vokabular
8b	Reiter in /soa und /audit-readiness	zurückgestellt (§7a)
9	ISO-Exporte: SoA + Annex-A-Gap	Managementbewertung hat ihre Eingabe

Schritte 1–4 sind Pflicht und hängen aneinander. 5–9 sind danach teilbar.

---

9. Definition of Done

Prüfung	Erwartung
Snapshot-Test TISAX	0 Abweichungen zur Ausgabe vor dem Umbau
Reiner ISO-Mandant	Readiness und SoA rechnen; keine AL-, Prüfziel- oder Reifegrad-Begriffe in der Oberfläche
Reiner TISAX-Mandant	Verhalten und Beschriftung unverändert
Doppel-Mandant	zurückgestellt — Architektur trägt es, Oberfläche zeigt es noch nicht (§7a)

| ISO-Delta | die 33 Anforderungen ohne ISA-Gegenstück sind als eigene Liste ausweisbar | | Gate | tsc, lint, build, _verify*, _render_diff, beide Testskripte grün |

---

10. Aufwand und Risiken

Aufwand: 4–6 PT im vorgezogenen Umfang (§7a), 5–8 PT vollständig. Schwerpunkt liegt auf Schritt 4 (verhaltensgleiche Extraktion) und Schritt 8 (zwei Sichten statt einer), nicht auf der ISO-Logik selbst — die ist schlank.

Risiko	Gegenmaßnahme
TISAX-Regression bei der Extraktion	Snapshot-Test vor Schritt 2 anlegen, als Merge-Gate setzen
Belegbasis wandert versehentlich in die Strategie	Review-Kriterium: loadEvidenceResolver darf FrameworkKey nicht kennen
Gemischte Kennzahlen schleichen sich in die UI	ReadinessSummary je Framework typisieren, keine Aggregation über beide
ISO-Scope hängt an gepflegter SoA	leere SoA → Readiness meldet „Anwendbarkeit noch nicht erklärt" statt 0 %
Doppelte Datenpflege beim Doppel-Mandanten	Schritt 7 ist nicht optional

---

11. Was ausdrücklich nicht gebaut wird

• Kein Reiter über Richtlinien, Nachweisen, Assets, Risiken oder Aufgaben.
• Keine gemeinsame Kennzahl über beide Frameworks.
• Kein Reifegrad als ISO-Erfüllungsaussage (optionale Zusatzspalte ja, Bewertungsgrundlage nein).
• Keine Änderung an der VDA-ISA-Logik über die reine Extraktion hinaus.
• Kein Umbau von readiness.ts/gap-consolidation.ts — die Rechen-Engines sind numerisch standard-agnostisch und werden von beiden Strategien gefüttert.