Benjamin_Boenisch/breakpilot-compliance
1
1
Fork 0
Code Issues 24 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f3d3255de1b03ddcf9375b51255e9f5a7947e35b
breakpilot-compliance/docs-src/architecture/transition-reasoning/master-delta-questions-v1.md
T
Benjamin Admin fe21c2f487 docs(spec): Transition Reasoning spec v1 + MDQ Registry + ADR-002 
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>
2026-06-27 07:03:42 +02:00

6.5 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.

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)

  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