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

```ts
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)

```ts
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.