Benjamin Admin
3856bb3a4f
Second mission, deliberately different from #1: a highly-certified company (ISO 9001 + ISO 27001 + ISO 14001 + TISAX + CE + PSIRT) asking „what do WE still need for the CRA?". Stresses Mission #1's one open seam (Scope → Journey) and proves the reframe with the real engines: - The start is a Company Capability Profile (certs aggregated), NOT a single cert→target journey. Certifications are OBSERVATIONS feeding the profile. - Evidence is target-relative: ISO 14001 is in the profile but irrelevant to the CRA; PSIRT covers two CRA-delta capabilities. More evidence = smaller delta (12 → 9). - The „journey" is the computed delta (Profile, Target) — not a thing a selector picks. This SHRINKS Mission #1's jump: the seam is profile-intake + target-pick, not a journey-matcher engine. There is no „ISO 27001 → CRA"; only „Profile → CRA". Records the 5 per-mission selection-rationale questions (which journey/why/decisive info/model-extended?/new-parameter?). Selector input = (Company Profile, Target), which collapses the 2^N cert-combination explosion. Non-runtime (reference_scenarios + tests only) -> no deploy. 6 tests pass; check-loc 0.
5.6 KiB
Customer Mission #2 — „Wir haben SCHON viel. Was fehlt UNS noch für die CRA?"
Zweite Mission, bewusst ANDERS als #1: nicht „ein Zertifikat → ein Ziel", sondern ein hoch-zertifiziertes Unternehmen, das mit einem ganzen Profil ankommt. Test der einzigen offenen Naht aus Mission #1 (Scope → Journey). Synthetischer Kunde, keine echten Namen.
Der Kunde (synthetisch, hoch-zertifiziert)
ISO 9001 · ISO 27001 · ISO 14001 · TISAX · CE-Prozess · PSIRT · vernetzte Maschinen · Export EU Eine Frage: „Wir sind schon in vielem zertifiziert — was genau fehlt UNS noch, um CRA-konform zu sein?"
0. Company Capability Profile — der eigentliche Startzustand
Das Unternehmen bringt kein Zertifikat als Startpunkt, sondern ein Profil. Jedes Zertifikat ist eine Beobachtung, die wahrscheinliche Fähigkeiten beisteuert; der Startzustand ist ihre Aggregation.
| Zertifikat (Beobachtung) | steuert Fähigkeiten bei | Vertrauen |
|---|---|---|
| ISO27001 — Informationssicherheit (ISMS) | incident_management, technical_vulnerability_management, access_control_and_authentication, secure_development_lifecycle, security_logging_and_monitoring |
medium |
| TISAX — Automotive-ISMS — verstärkt dieselben Infosec-Fähigkeiten | incident_management, technical_vulnerability_management, access_control_and_authentication, secure_development_lifecycle, security_logging_and_monitoring |
medium |
| PSIRT — Product-Security-Incident-Response — deckt ZWEI CRA-Delta-Fähigkeiten | coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting |
high |
| ISO9001 — QM-Dokumentendisziplin → CE-/Technische-Doku-Fähigkeit | ce_conformity_assessment_and_technical_documentation |
medium |
| ISO14001 — Umweltmanagement — im Profil, aber für die CRA NICHT relevant | environmental_management_documentation |
medium |
→ Evidence ist zielrelativ: ISO 14001 liegt im Profil, hilft der CRA aber nicht; PSIRT (oft übersehen) deckt zwei CRA-kritische Delta-Fähigkeiten. Genau deshalb darf man nicht ein Zertifikat zur Journey machen — das ganze Profil zählt.
1. Ziel (Intent) — was wollen Sie erreichen?
- Intent: „CRA-konform werden" → Ziel-Profil = CRA (die von der CRA geforderten Fähigkeiten).
- Auswahl-Eingabe ist damit (Company Profile, Ziel) — kein Zertifikat, das auf eine Journey gemappt wird.
2. Capability Delta — Profil → CRA (das IST die „Journey")
17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.
- Delta dieses Profils: 9 fehlende Fähigkeiten.
- Gegenprobe (nur ISO 27001): 12 fehlende Fähigkeiten.
- Mehr Evidence → kleineres Delta: die zusätzliche Zertifizierung schließt 3 Fähigkeiten vorab:
ce_conformity_assessment_and_technical_documentation,coordinated_vulnerability_disclosure,exploited_vuln_and_incident_reporting.
→ Es wurde keine Journey ausgewählt. Das Delta (Profil, Ziel) IST die Journey — berechnet, nicht gewählt. Die Journey ist nur die Erklärung dieses Deltas.
3. Roadmap — was zuerst? (gleicher Hebel-Engine wie Mission #1)
12 identifizierte Anforderungen aus 2 Regelwerken -> 9 Massnahmen (Ø Hebel 1.3).
- Top-5 nach Hebel schließen 8 von 12 offenen Anforderungen (67%).
Selektions-Rationale — die 5 Fragen (pro Mission zu dokumentieren)
Welche Journey wurde gewählt?
Keine per-Zertifikat-Journey. Die Journey ist Company Capability Profile → CRA. Gewählt wurde nur das Ziel (CRA); der Startzustand wurde aus ALLEN Zertifikaten aggregiert.
Warum?
Bei 6 Zertifikaten würde „ISO 27001 → CRA" die Evidence aus PSIRT/ISO 9001 wegwerfen (= 3 Fähigkeiten, die sonst fälschlich als Delta erschienen). Nur das ganze Profil ergibt das korrekte Delta.
Welche Informationen waren für die Auswahl entscheidend?
(a) das Ziel/Intent (CRA) und (b) die vollständige Zertifikatsliste als Profil — nicht ein einzelnes Zertifikat. Welche Evidence hilft, ist zielrelativ (ISO 14001 irrelevant, PSIRT hoch-relevant).
Musste das Journey-Modell erweitert werden?
Konzeptionell ja, strukturell nein. from → to bleibt; aber from ist ein Company Capability Profile (Multi-Cert-Aggregat), kein Zertifikat. Die Engines (build_company_profile + assess_transition) tun das BEREITS — es war ein Benenn-/Framing-Fehler, kein fehlender Code.
Musste ein neuer Selektionsparameter eingeführt werden?
Ja — und er VEREINFACHT. Eingabe ist (Company Profile, Ziel), nicht (Zertifikat, Ziel). Die Zertifikate kollabieren ins Profil → keine 2^N Cert-Kombinationen, nur Profil→Ziel. Der Selektor wird damit kleiner, nicht größer.
Was Mission #2 an Mission #1 verändert
- Mission #1 nannte Scope → Journey einen Sprung („kein Selektor
certs × targets → journeys"). Mission #2 zeigt: diese Naht schrumpft. Es gibt keinen Journey-Matcher zu bauen — die Journey ist das berechnete Delta(Profil, Ziel). Was real fehlt, ist nur Profil-Intake + Ziel-Wahl, nicht eine Journey-Auswahl-Engine. - Bestätigt den Reframe: Es gibt keine „ISO 27001 → CRA"-Transition — nur „Company Capability Profile → CRA". Zertifikate sind Beobachtungen/Evidence, kein Journey-Startpunkt.
- Beobachtung für den (noch nicht gebauten) Selektor: Eingabe =
(Company Profile, Ziel). Diversität über weitere Missionen muss zeigen, ob auch Produktprofil und Intent-Klasse als Parameter nötig werden — erst dann kanonisieren (rule-of-three-canonicalization).