Benjamin Admin
24fdde89c6
v1.1: interview questions are GENERATED from the existing (Master) Controls, not hand-written. Three building blocks: Control->question_intent (corpus/Execution), ~30-40 Master Question Templates (Reasoning), Transition-Prioritization (certs decide which generated questions can be skipped; 217->19 funnel, reuses Company 2A + cert map). v1.2: knowledge production. LLMs produce the first expert DRAFT (the prioritization per transition); BreakPilot reviews + versions + OWNS the canonical library (in Git, not the AI; model-independent, MDQ-00127 v4). Offline multi-model workflow, NOT runtime (deterministic-first: LLM offline-propose, never online-mutate). Hard boundary: the library is an expert DRAFT, not a normative/legal proof -- "cert probably covers X" is Welt-1 (ClaimCoverage), never "erfuellt" (anti-fake-evidence). Reframes the 100 seed questions as validation/template-extraction set. Spec only, no code; non-runtime docs -> no deploy (ADR-001). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
149 lines
6.9 KiB
Markdown
149 lines
6.9 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.
|
||
|
||
## Rolle dieser Liste (nach Spec-Revision v1.1/v1.2)
|
||
|
||
Diese 100 sind **NICHT die Bibliothek**. Laut Spec v1.1 werden Fragen aus den **Controls generiert**
|
||
(`Control × Master Question Template`), nicht von Hand geschrieben; das Expertenwissen steckt in der
|
||
**Priorisierung** (welche Frage eine Zertifizierung überspringbar macht), die laut v1.2 als LLM-Entwurf
|
||
entsteht und dann von BreakPilot **reviewt + versioniert + besessen** wird. Diese 100 dienen daher als:
|
||
- **Validierungsset** — entsteht aus dem Generate-from-Controls-Pfad eine vergleichbare Frage?
|
||
- **Quelle für die ~30–40 Master Question Templates** (Intents per Clustern extrahieren).
|
||
- **Seed/Beispiel** für den „1000 MDQ in 30 Tagen"-Workflow.
|
||
|
||
Siehe [`../transition-reasoning-spec-v1.md`](../transition-reasoning-spec-v1.md) (v1.2).
|
||
|
||
---
|
||
|
||
## 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?
|