craftvia/docs/FRAMEWORK-MAPPING-ISO27001.md

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:

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

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).