# ISO/IEC 27001:2022 auf der gemeinsamen Dokumentenbibliothek (Variante A)

**Stand:** 2026-08-27 · **Paket:** `seed/isms-vorlagenpaket-v2` (+ `-en`) · **Status:** umgesetzt, ISB-Freigabe offen

> **Entscheidung:** Ein Dokumentensatz, zwei Framework-Mappings. Die bestehenden Richtlinien und
> Verfahren bleiben die einzige Quelle; ISO/IEC 27001 wird als zweites Mapping darübergelegt.
> Damit ersetzt diese Umsetzung die ursprüngliche Annahme aus `KONZEPT-framework-iso27001.md`
> (D4: zweites Seed-Paket `seed/isms-iso27001-v1/`).

---

## 1. Warum nicht zwei Pakete

`PolicyDocument` ist über `@@unique([tenantId, code])` eindeutig. Zwei Pakete mit denselben
Dokument-Codes (`L00`, `R01`…`R14`, `VA-01`…`VA-20`) können in einem Mandanten nicht nebeneinander
existieren — der zweite Import überschreibt beim Upsert den Inhalt des ersten und archiviert die
Dokumente, die im anderen Paket fehlen. Für einen Mandanten mit ISO **und** TISAX wäre das Ergebnis
das Gegenteil der Absicht.

Hinzu kommt der fachliche Punkt: Die Umsetzungsbeschreibung („Umsetzung bei {{ORG_NAME}}") ist
normunabhängig. Wie eine Organisation Berechtigungen vergibt, ändert sich nicht dadurch, ob ISO oder
VDA ISA danach fragt. Sie zweimal zu pflegen erzeugt Widersprüche.

## 2. Aufbau

| Bestandteil | Rolle |
|---|---|
| `richtlinien/`, `verfahren/` | **gemeinsame** Dokumente — ein Umsetzungstext je Thema |
| `mapping.json` | Framework-Mapping **VDA ISA 2027** (321 Anforderungen) |
| `mapping-iso.json` | Framework-Mapping **ISO/IEC 27001:2022** (120 Anforderungen) |
| `_iso_crosswalk.json` | fachliche Zuordnung ISO-Anforderung → Dokument + Abschnitt (redaktionell) |
| `_iso_sections.json` / `_iso_sections_en.json` | Texte der ISO-only-Abschnitte (redaktionell, je Sprache) |
| `_iso_texts_en.json` | englische Anforderungstexte (Struktur bleibt im Crosswalk) |
| `_generate_iso.py` | erzeugt aus beidem die Dokument-Patches, `mapping-iso.json` und die SoA |
| `_verify.py` / `_verify_iso.py` | prüfen je eine Framework-Sicht |
| `Statement-of-Applicability-ISO.md` | SoA-Gerüst mit den Pflichtangaben aus 6.1.3 d) |

### Sichtbarkeitssteuerung über Platzhalter

Zwei neue Flags in `variables.schema.json` steuern, welche Anforderungssicht ein Mandant sieht:

| Flag | Default | Wirkung |
|---|---|---|
| `FLAG_FW_TISAX` | `true` | VDA-ISA-Anforderungsblöcke sichtbar |
| `FLAG_FW_ISO27001` | `false` | ISO-Anforderungsblöcke und ISO-only-Abschnitte sichtbar |

Im Dokument sieht das so aus — der Umsetzungstext steht **einmal** und gilt für beide:

```markdown
### 3.2 Sichere Anmeldung

*Anforderungsbezug:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.5{{/if}}

**Anforderung**

{{#if FLAG_FW_TISAX}}
- **[MUSS]** Verfahren zur Benutzerauthentifizierung nach dem Stand der Technik werden angewandt.
{{/if}}
{{#if FLAG_FW_ISO27001}}
- **[ISO A.8.5]** Sichere Authentisierungstechnologien und -verfahren sind einzusetzen.
{{/if}}

**Umsetzung bei {{ORG_NAME}}**

<!-- IMPL 4.1.2 -->
Die Authentifizierungsverfahren sind risikobasiert ausgewählt … Passwortvorgaben nach BL-IAM-01 …
```

Beide Mappings zeigen mit `impl_anchor` auf denselben Block `IMPL 4.1.2`.

## 3. Abdeckung

- **120 ISO-Anforderungen:** 27 Klauseln (Kap. 4–10, inkl. 6.3 aus Amd 1:2024) + 93 Anhang-A-Controls
  in der Verteilung 37/8/14/34.
- **43 Abschnitte** der Bibliothek werden von beiden Frameworks genutzt.
- **19 ISO-only-Abschnitte** wurden ergänzt, wo VDA ISA kein Gegenstück hat:

| Dokument | Neue Abschnitte | ISO-Bezug |
|---|---|---|
| L00 | Politik, Ziele, Kommunikation | 5.2, 6.2, 7.4, A.5.1 |
| R01 | Kontext/Scope · Änderungsplanung · Dokumentenlenkung · Behördenkontakte | 4.1–4.4, 6.3, 7.5.1–7.5.3, A.5.5, A.5.6 |
| R02 | Datenmaskierung | A.8.11 |
| R03 | SoA · Betriebliche Planung · Messung · Managementbewertung · CAPA | 6.1.3, 8.1, 9.1, 9.3, 10.1, 10.2 |
| R05 | Vorgehen bei Verstößen | A.6.4 |
| R07 | Umgebungsschutz/Versorgung/Verkabelung/Wartung · Clear Desk | A.7.5, A.7.7, A.7.8, A.7.11–A.7.13 |
| R10 | Bedrohungsinformationen · Betriebsabläufe · Kapazität · Datenabfluss · Zeitsynchronisation | A.5.7, A.5.37, A.8.6, A.8.12, A.8.17 |

Die neuen Abschnitte sind ausschließlich über Platzhalter individualisierbar — wie die
Bestandstexte. Dafür kamen elf Variablen und acht Baseline-Parameter hinzu
(`BL-OPS-10/11/12`, `BL-NET-03`, `BL-PHY-03/04`, `BL-GOV-02/03`).

**Ohne ISO-Bezug** bleibt nur der Abschnitt „Nutzung von KI-/GenAI-Diensten" (eigene Ergänzung) sowie
die Dokumente `P01` (Prototypenschutz) und `D01` (Datenschutz-Prüfziel) — beides TISAX-spezifisch.

## 4. Änderungen am Anwendungscode

Zwei Stellen, beide klein und rückwärtskompatibel:

1. **`prisma/import-policies.ts`** — der Umsetzungstext wird jetzt über `impl_anchor` aufgelöst
   (`IMPL 4.1.2`), mit Rückfall auf die Anforderungs-ID und auf ein `implementation`-Feld im Mapping.
   *Nebeneffekt:* Das behebt einen Bestandsfehler. Bisher wurde `implMap.get(a.id)` gesucht — die
   Anforderungs-IDs (`4.1.2-M1`) haben aber keinen eigenen IMPL-Block, sodass **alle 321**
   VDA-ISA-Anforderungen mit leerem Umsetzungstext importiert wurden. Sichtbar war das u. a. in der
   Spalte „Umsetzung" unter `/policies` und in der Plattform-Vorlagenverwaltung. Nach der Korrektur
   bleiben 12 leere Einträge (L00 — die Leitlinie hat bewusst keine IMPL-Blöcke).
2. **`src/lib/policy-render.ts`** — `buildContext` belegt fehlende Framework-Flags vor
   (`FLAG_FW_TISAX = true`, `FLAG_FW_ISO27001 = false`). Ohne das würden Bestandsmandanten, deren
   Vorlagenpaket noch nicht neu importiert wurde, die VDA-ISA-Anforderungsblöcke leer sehen.

## 5. Prüfung

```bash
cd seed/isms-vorlagenpaket-v2
python3 _generate_iso.py               # deutsche Fassung, idempotent
python3 _generate_iso.py --lang en     # englische Fassung
python3 _verify.py                     # TISAX-Sicht  → OK
python3 _verify_iso.py                 # ISO-Sicht DE → OK
python3 _verify_iso.py --lang en       # ISO-Sicht EN → OK
```

`_verify_iso.py` prüft Vollständigkeit (27 + 93), Auflösbarkeit aller Anker, nicht leere
Umsetzungsblöcke, das Rendering **beider** Sichten ohne offene Platzhalter sowie die Verknüpfung zu
den Verfahren.

## 6. Was noch fehlt (Anwendungsseite)

Das Paket ist fertig; die Anwendung kennt das zweite Mapping noch nicht. Offen bleibt aus
`KONZEPT-framework-iso27001.md`:

- **Lane 1** — `Framework`-Enum, `TenantFramework`, `framework` an `PolicyTemplateVersion` und
  `PolicyPackageState`. Erst damit lässt sich `mapping-iso.json` überhaupt importieren; heute liest
  `parsePackageFiles` fest `mapping.json`.
- **Lane 3/4** — ISO-Assessment (Applicability statt Reifegrad) und das **SoA-Modul**. Bis dahin wird
  die SoA als gelenktes Dokument geführt (`Statement-of-Applicability-ISO.md`).
- **Setzen der Flags** — beim Provisionieren eines ISO-Mandanten müssen `FLAG_FW_ISO27001 = true`
  und, falls kein TISAX, `FLAG_FW_TISAX = false` gesetzt werden.

Ebenfalls offen und unabhängig davon: `REVIEW_CYCLE` wird weiterhin für fünf verschiedene Zyklen
verwendet. Die neuen Abschnitte nutzen bereits die getrennten Variablen
(`POLICY_REVIEW_CYCLE`, `MGMT_REVIEW_CYCLE`, `RISK_REVIEW_CYCLE`); die Bestandstexte umzustellen ist
eine eigene, kleine Änderung.

## 7. Urheberrechtlicher Hinweis

Die ISO-Anforderungstexte in `mapping-iso.json` und in den Dokumenten sind **eigene Paraphrasen**;
die Referenzen sind exakt, damit in der erworbenen Norm nachgeschlagen werden kann. Wörtliche
Normzitate sind bewusst unterlassen. Das VDA-ISA-Mapping übernimmt die Anforderungen laut eigenem
Hinweis in `mapping.json` „1:1 aus ISA" — auch dieser Katalog ist geschützt. Bei der weiteren Pflege
der gemeinsamen Bibliothek sollte die vorsichtigere Linie des ISO-Mappings die gemeinsame werden
(vgl. `SPEC.md` §12).