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