msolarczekandClaude Opus 5
c8e6f30a27
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
291 lines
15 KiB
Markdown
291 lines
15 KiB
Markdown
# 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.
|