Benjamin_Boenisch/breakpilot-compliance
1
1
Fork 0
Code Issues 24 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
77d6bc5551511ac5ffb9807f7f69ddf371dc3cb8
breakpilot-compliance/docs-src/architecture/transition-reasoning/master-delta-questions-v1.md
T
Benjamin Admin 24fdde89c6 docs(spec): Transition Reasoning v1.2 — questions generated from controls + AI-drafted curated library 
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>
2026-06-27 07:11:53 +02:00

6.9 KiB
Raw Blame History

Master Delta Questions — v1 (Seed-Library)

  • Status: v1 Seed — 2026-06-27. Gehört zu ../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 (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)

  1. Gibt es einen dokumentierten Entwicklungsprozess?
  2. Werden Anforderungen versioniert?
  3. Werden Änderungen nachvollziehbar dokumentiert?
  4. Werden Architekturentscheidungen dokumentiert?
  5. Existieren Design Reviews?
  6. Werden Sicherheitsanforderungen bereits in der Entwicklung berücksichtigt?
  7. Gibt es definierte Freigabekriterien?
  8. Existiert ein Releaseprozess?
  9. Werden Softwareversionen eindeutig identifiziert?
  10. Existiert eine Produktstückliste (BOM)?

Bereich C — Software & Firmware (21–30)

  1. Enthält Ihr Produkt Software?
  2. Enthält Ihr Produkt Firmware?
  3. Werden Firmwareupdates ausgeliefert?
  4. Erfolgen Updates lokal oder remote?
  5. Können Updates automatisiert verteilt werden?
  6. Werden Updatepakete signiert?
  7. Wird die Integrität von Updates geprüft?
  8. Existiert eine Rollback-Strategie?
  9. Werden Softwarekomponenten versioniert?
  10. Werden Drittanbieterbibliotheken dokumentiert?

Bereich D — SBOM & Komponenten (31–40)

  1. Wird für jede Version automatisch eine SBOM erzeugt?
  2. Welches SBOM-Format verwenden Sie?
  3. Wird die SBOM versioniert?
  4. Enthält die SBOM alle Softwarekomponenten?
  5. Enthält sie Open-Source-Komponenten?
  6. Enthält sie proprietäre Komponenten?
  7. Wird die SBOM Kunden bereitgestellt?
  8. Wird sie intern gepflegt?
  9. Wird sie automatisiert erzeugt?
  10. Wie wird ihre Aktualität sichergestellt?

Bereich E — Vulnerability Management (41–50)

  1. Existiert ein dokumentierter Vulnerability-Management-Prozess?
  2. Wer bewertet gemeldete Schwachstellen?
  3. Wie werden CVEs verfolgt?
  4. Gibt es definierte Reaktionszeiten?
  5. Werden Schwachstellen priorisiert?
  6. Existiert ein PSIRT?
  7. Gibt es einen Meldeprozess für Kunden?
  8. Werden Security Advisories veröffentlicht?
  9. Werden behobene Schwachstellen dokumentiert?
  10. Wird der Prozess regelmäßig überprüft?

Bereich F — Security Updates (51–60)

  1. Gibt es eine dokumentierte Update-Richtlinie?
  2. Wie lange liefern Sie Sicherheitsupdates?
  3. Wie informieren Sie Kunden über Updates?
  4. Wie wird die Authentizität von Updates sichergestellt?
  5. Werden Notfallupdates unterstützt?
  6. Können Updates zurückgezogen werden?
  7. Können Kunden Updates ablehnen?
  8. Werden Updatefehler protokolliert?
  9. Gibt es einen definierten Update-Lifecycle?
  10. Wer verantwortet den Updateprozess?

Bereich G — Lieferanten (61–70)

  1. Werden Lieferanten sicherheitsbezogen bewertet?
  2. Gibt es Sicherheitsanforderungen an Lieferanten?
  3. Werden Softwarelieferanten regelmäßig überprüft?
  4. Werden Lieferantenänderungen dokumentiert?
  5. Werden Sicherheitsvorfälle von Lieferanten verfolgt?
  6. Werden Lieferantenverträge regelmäßig überprüft?
  7. Existieren Mindestanforderungen für Softwarelieferanten?
  8. Werden Lieferanten auditiert?
  9. Gibt es einen Eskalationsprozess?
  10. Wie werden kritische Lieferanten identifiziert?

Bereich H — Betrieb & Support (71–80)

  1. Existiert ein Incident-Response-Prozess?
  2. Gibt es einen Security-Support?
  3. Werden Sicherheitsvorfälle dokumentiert?
  4. Gibt es definierte Eskalationsstufen?
  5. Werden Kunden über Vorfälle informiert?
  6. Existiert ein Backupkonzept?
  7. Gibt es Wiederherstellungstests?
  8. Werden Supportanfragen klassifiziert?
  9. Gibt es definierte Servicezeiten?
  10. Werden Lessons Learned dokumentiert?

Bereich I — Nachweise (81–90)

  1. Welche Richtlinien können Sie unmittelbar bereitstellen?
  2. Welche Prozesse sind dokumentiert?
  3. Welche Arbeitsanweisungen existieren?
  4. Welche Auditberichte liegen vor?
  5. Welche Zertifikate liegen aktuell vor?
  6. Welche technischen Nachweise können Sie liefern?
  7. Welche Protokolle werden archiviert?
  8. Welche Nachweise werden versioniert?
  9. Welche Nachweise sind öffentlich verfügbar?
  10. Welche Nachweise fehlen derzeit?

Bereich J — Neue regulatorische Anforderungen (91–100)

  1. Erzeugen Sie Nutzungsdaten Ihrer Produkte?
  2. Unterstützen Ihre Produkte Fernwartung?
  3. Enthalten Ihre Produkte Funkmodule?
  4. Werden sicherheitsrelevante Ereignisse protokolliert?
  5. Gibt es Umweltaspekte wie Chemikalien oder Abwasser?
  6. Werden Umweltmessdaten dokumentiert?
  7. Gibt es produktspezifische Entsorgungsanforderungen?
  8. Gibt es dokumentierte Cyber-Risikoanalysen?
  9. Welche neuen regulatorischen Anforderungen sehen Sie selbst als größte Herausforderung?
  10. Welche regulatorischen Nachweise möchten Sie innerhalb der nächsten zwölf Monate erstmals oder zusätzlich erfüllen?
Reference in New Issue View Git Blame Copy Permalink