Benjamin Admin
fe21c2f487
Second reasoning mode (extends, does not replace): BreakPilot answers MIGRATION questions (start state -> target state -> delta), not regulation Q&A. New package compliance/transition_reasoning/ (spec only). Transition Reasoning is RCI generalized; reuses Company 2A (have), Master Capability Registry (MCAP) and RCI. MDQ Registry = 4th identity-machine instance (after Master Controls/Obligations/ Capabilities): every Master Delta Question is a versioned, identifiable knowledge unit (verifies MCAP, supports obligations, transition patterns, evidence types, information gain, confidence impact, follow-up). Transition Patterns hold only MDQ references -> reuse across transitions. Delta interview = information-gain optimization, not a sequential questionnaire. ADR-002: transitions are DATA (patterns + capability/MDQ knowledge), never engine or metamodel extensions. 100 seed questions captured as v1. Spec only (no code; freeze-respecting: additive package, no new graph/base class/ meta-model class). Non-runtime docs -> no deploy (ADR-001). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
144 lines
6.5 KiB
Markdown
144 lines
6.5 KiB
Markdown
# Master Delta Questions — v1 (Seed-Library)
|
||
|
||
- **Status:** v1 Seed — 2026-06-27. Gehört zu [`../transition-reasoning-spec-v1.md`](../transition-reasoning-spec-v1.md).
|
||
- **Sortierung nach Operational Capability, nicht nach Regelwerk** — dadurch werden Fragen über
|
||
Transitions hinweg wiederverwendbar (dieselbe Frage ist für CRA, IEC 62443, NIS2 und teils TISAX relevant).
|
||
|
||
## Herkunft der Fragen (warum es wenige sind)
|
||
|
||
- **Regulatorische Pflichten** (CRA, MaschVO, NIS2, Data Act, Umweltrecht …) sagen, **welche
|
||
Capability benötigt** wird.
|
||
- **Bestehende Zertifizierungen** (ISO 27001, TISAX, ISO 9001, ISO 14001, IATF 16949 …) sagen,
|
||
**welche Capability wahrscheinlich bereits existiert**.
|
||
- Die Bibliothek schließt **nur die Unsicherheit dazwischen** → dieselbe Frage in vielen Übergängen
|
||
wiederverwendbar. Erwartung: am Ende **~300–500 Master Delta Questions**, nicht 5.000.
|
||
|
||
## v1 → v2 (Ziel)
|
||
|
||
Diese 100 sind v1: noch nach Themen gruppiert, noch **un-indexiert**. v2 hebt jede Frage in das
|
||
MDQ-Schema (siehe Spec): `id (MDQ-xxxxx)` · `verifies: [MCAP-id]` · `supports_obligations` ·
|
||
`transition_patterns` · `expected_evidence` · `information_gain` · `confidence_impact` · `follow_up`
|
||
· `version/status/lifecycle`. Erst dann werden sie zur **MDQ Registry** (4. Identitätsmaschine-Instanz).
|
||
|
||
---
|
||
|
||
## Bereich A — Unternehmenskontext (1–10)
|
||
1. Welche Managementsysteme sind aktuell im Unternehmen eingeführt?
|
||
2. Welche Zertifizierungen sind derzeit gültig?
|
||
3. Welche Zertifizierungen befinden sich aktuell in Vorbereitung?
|
||
4. Welche regulatorischen Anforderungen möchten Sie als Nächstes erfüllen?
|
||
5. Welche Länder und Märkte beliefern Sie?
|
||
6. Welche Rolle nehmen Sie ein (Hersteller, Integrator, Importeur, Betreiber, Service)?
|
||
7. Entwickeln Sie eigene Produkte oder integrieren Sie Komponenten Dritter?
|
||
8. Entwickeln Sie eigene Software oder Firmware?
|
||
9. Welche Nachweise können Sie heute bereits unmittelbar bereitstellen?
|
||
10. Welche regulatorischen Themen bereiten Ihnen derzeit die größten Schwierigkeiten?
|
||
|
||
## Bereich B — Produktentwicklung (11–20)
|
||
11. Gibt es einen dokumentierten Entwicklungsprozess?
|
||
12. Werden Anforderungen versioniert?
|
||
13. Werden Änderungen nachvollziehbar dokumentiert?
|
||
14. Werden Architekturentscheidungen dokumentiert?
|
||
15. Existieren Design Reviews?
|
||
16. Werden Sicherheitsanforderungen bereits in der Entwicklung berücksichtigt?
|
||
17. Gibt es definierte Freigabekriterien?
|
||
18. Existiert ein Releaseprozess?
|
||
19. Werden Softwareversionen eindeutig identifiziert?
|
||
20. Existiert eine Produktstückliste (BOM)?
|
||
|
||
## Bereich C — Software & Firmware (21–30)
|
||
21. Enthält Ihr Produkt Software?
|
||
22. Enthält Ihr Produkt Firmware?
|
||
23. Werden Firmwareupdates ausgeliefert?
|
||
24. Erfolgen Updates lokal oder remote?
|
||
25. Können Updates automatisiert verteilt werden?
|
||
26. Werden Updatepakete signiert?
|
||
27. Wird die Integrität von Updates geprüft?
|
||
28. Existiert eine Rollback-Strategie?
|
||
29. Werden Softwarekomponenten versioniert?
|
||
30. Werden Drittanbieterbibliotheken dokumentiert?
|
||
|
||
## Bereich D — SBOM & Komponenten (31–40)
|
||
31. Wird für jede Version automatisch eine SBOM erzeugt?
|
||
32. Welches SBOM-Format verwenden Sie?
|
||
33. Wird die SBOM versioniert?
|
||
34. Enthält die SBOM alle Softwarekomponenten?
|
||
35. Enthält sie Open-Source-Komponenten?
|
||
36. Enthält sie proprietäre Komponenten?
|
||
37. Wird die SBOM Kunden bereitgestellt?
|
||
38. Wird sie intern gepflegt?
|
||
39. Wird sie automatisiert erzeugt?
|
||
40. Wie wird ihre Aktualität sichergestellt?
|
||
|
||
## Bereich E — Vulnerability Management (41–50)
|
||
41. Existiert ein dokumentierter Vulnerability-Management-Prozess?
|
||
42. Wer bewertet gemeldete Schwachstellen?
|
||
43. Wie werden CVEs verfolgt?
|
||
44. Gibt es definierte Reaktionszeiten?
|
||
45. Werden Schwachstellen priorisiert?
|
||
46. Existiert ein PSIRT?
|
||
47. Gibt es einen Meldeprozess für Kunden?
|
||
48. Werden Security Advisories veröffentlicht?
|
||
49. Werden behobene Schwachstellen dokumentiert?
|
||
50. Wird der Prozess regelmäßig überprüft?
|
||
|
||
## Bereich F — Security Updates (51–60)
|
||
51. Gibt es eine dokumentierte Update-Richtlinie?
|
||
52. Wie lange liefern Sie Sicherheitsupdates?
|
||
53. Wie informieren Sie Kunden über Updates?
|
||
54. Wie wird die Authentizität von Updates sichergestellt?
|
||
55. Werden Notfallupdates unterstützt?
|
||
56. Können Updates zurückgezogen werden?
|
||
57. Können Kunden Updates ablehnen?
|
||
58. Werden Updatefehler protokolliert?
|
||
59. Gibt es einen definierten Update-Lifecycle?
|
||
60. Wer verantwortet den Updateprozess?
|
||
|
||
## Bereich G — Lieferanten (61–70)
|
||
61. Werden Lieferanten sicherheitsbezogen bewertet?
|
||
62. Gibt es Sicherheitsanforderungen an Lieferanten?
|
||
63. Werden Softwarelieferanten regelmäßig überprüft?
|
||
64. Werden Lieferantenänderungen dokumentiert?
|
||
65. Werden Sicherheitsvorfälle von Lieferanten verfolgt?
|
||
66. Werden Lieferantenverträge regelmäßig überprüft?
|
||
67. Existieren Mindestanforderungen für Softwarelieferanten?
|
||
68. Werden Lieferanten auditiert?
|
||
69. Gibt es einen Eskalationsprozess?
|
||
70. Wie werden kritische Lieferanten identifiziert?
|
||
|
||
## Bereich H — Betrieb & Support (71–80)
|
||
71. Existiert ein Incident-Response-Prozess?
|
||
72. Gibt es einen Security-Support?
|
||
73. Werden Sicherheitsvorfälle dokumentiert?
|
||
74. Gibt es definierte Eskalationsstufen?
|
||
75. Werden Kunden über Vorfälle informiert?
|
||
76. Existiert ein Backupkonzept?
|
||
77. Gibt es Wiederherstellungstests?
|
||
78. Werden Supportanfragen klassifiziert?
|
||
79. Gibt es definierte Servicezeiten?
|
||
80. Werden Lessons Learned dokumentiert?
|
||
|
||
## Bereich I — Nachweise (81–90)
|
||
81. Welche Richtlinien können Sie unmittelbar bereitstellen?
|
||
82. Welche Prozesse sind dokumentiert?
|
||
83. Welche Arbeitsanweisungen existieren?
|
||
84. Welche Auditberichte liegen vor?
|
||
85. Welche Zertifikate liegen aktuell vor?
|
||
86. Welche technischen Nachweise können Sie liefern?
|
||
87. Welche Protokolle werden archiviert?
|
||
88. Welche Nachweise werden versioniert?
|
||
89. Welche Nachweise sind öffentlich verfügbar?
|
||
90. Welche Nachweise fehlen derzeit?
|
||
|
||
## Bereich J — Neue regulatorische Anforderungen (91–100)
|
||
91. Erzeugen Sie Nutzungsdaten Ihrer Produkte?
|
||
92. Unterstützen Ihre Produkte Fernwartung?
|
||
93. Enthalten Ihre Produkte Funkmodule?
|
||
94. Werden sicherheitsrelevante Ereignisse protokolliert?
|
||
95. Gibt es Umweltaspekte wie Chemikalien oder Abwasser?
|
||
96. Werden Umweltmessdaten dokumentiert?
|
||
97. Gibt es produktspezifische Entsorgungsanforderungen?
|
||
98. Gibt es dokumentierte Cyber-Risikoanalysen?
|
||
99. Welche neuen regulatorischen Anforderungen sehen Sie selbst als größte Herausforderung?
|
||
100. Welche regulatorischen Nachweise möchten Sie innerhalb der nächsten zwölf Monate erstmals oder zusätzlich erfüllen?
|