docs(knowledge): Reference Transition Scenarios (RTS-001..003) + ISO9001->CRA pattern
Three ANONYMIZED reference transition scenarios (no real company names stored) = canonical regression scenarios that test the KNOWLEDGE, not just the engine. Each pins an Expected Outcome (expected_likely_covered + expected_delta); every commit must reproduce it (identical or better). - RTS-001 automotive supplier (TISAX+ISO27001) -> CRA: mature ISMS, standard CRA delta. - RTS-002 classic machine builder (ISO9001) -> CRA: only process discipline -> MUCH larger delta (10 missing vs 3 covered). New TP-ISO9001-CRA-v1 pattern (different shape). - RTS-003 networked machine builder (ISMS) -> CRA: highlights the Data Act. Data Act is modelled as UNCERTAIN (a hypothesis), never a fixed gilt/gilt-nicht: the generator checks the engine SURFACES the uncertainty + the deciding question (generates_usage_data) and never wrongly ASSERTS applicability. All three RTS PASS. Non-runtime knowledge + reference harness -> no deploy (ADR-001). Names deliberately absent. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Benjamin Admin
@@ -0,0 +1,53 @@
|
||||
# Reference Transition Scenario — canonical regression scenario (NOT a test fixture).
|
||||
# ANONYMIZED ARCHETYPE ONLY — no real company names are stored in the system; illustrative.
|
||||
# Each RTS pins an Expected Outcome so every commit must reproduce it (identical or better).
|
||||
|
||||
id: RTS-001
|
||||
archetype: "Automotive supplier with a mature ISMS — embedded electronics + software, CE products, OEM supply chain"
|
||||
note: "Anonymized typical starting situation; illustrative only."
|
||||
|
||||
reference_company:
|
||||
sector: automotive_supply
|
||||
known_certifications: [TISAX, ISO27001]
|
||||
product_traits:
|
||||
is_machine: false # component / embedded supplier
|
||||
is_component: true
|
||||
has_embedded_software: true
|
||||
connected_to_internet: true
|
||||
has_remote_access: true
|
||||
generates_usage_data: null # UNKNOWN -> a deciding question, not an assertion
|
||||
market: [EU]
|
||||
|
||||
transition_goal:
|
||||
from: [TISAX, ISO27001]
|
||||
to:
|
||||
- target: CRA
|
||||
pattern: TP-ISO27001-CRA-v1 # executed through RS-005 below
|
||||
- target: MaschinenVO
|
||||
pattern: null
|
||||
note: pattern_pending # no MaschinenVO pattern yet
|
||||
|
||||
expected_outcome:
|
||||
cra:
|
||||
pattern: TP-ISO27001-CRA-v1
|
||||
# The mature ISMS reduces effort here (most info-security capabilities probably covered).
|
||||
expected_likely_covered_at_least:
|
||||
- incident_management
|
||||
- supplier_security
|
||||
- secure_development_lifecycle
|
||||
- asset_and_configuration_management
|
||||
- security_logging_and_monitoring
|
||||
- access_control_and_authentication
|
||||
# ... but the CRA product-cyber delta remains.
|
||||
expected_delta_at_least:
|
||||
- sbom_creation
|
||||
- coordinated_vulnerability_disclosure
|
||||
- security_update_support_period
|
||||
- secure_signed_update_distribution
|
||||
- exploited_vuln_and_incident_reporting
|
||||
- product_cyber_risk_assessment
|
||||
- ce_conformity_assessment_and_technical_documentation
|
||||
data_act:
|
||||
expectation: uncertain # NEVER a fixed gilt/gilt-nicht
|
||||
deciding_questions: [generates_usage_data, connected_product, data_act_scope]
|
||||
rationale: "A connected component MAY fall under the Data Act; applicability depends on usage-data generation + scope. The engine must SURFACE this uncertainty and ask, not assert."
|
||||
@@ -0,0 +1,50 @@
|
||||
# Reference Transition Scenario — ANONYMIZED ARCHETYPE ONLY (no real company names stored).
|
||||
id: RTS-002
|
||||
archetype: "Classic machine builder with only a QMS — precision systems, CE products, no ISMS"
|
||||
note: "Anonymized typical starting situation; illustrative only. Contrast to RTS-001: a much LARGER delta."
|
||||
|
||||
reference_company:
|
||||
sector: mechanical_engineering
|
||||
known_certifications: [ISO9001]
|
||||
product_traits:
|
||||
is_machine: true
|
||||
is_component: false
|
||||
has_embedded_software: true
|
||||
connected_to_internet: false # often not connected -> Data Act less likely, still a question
|
||||
has_remote_access: null
|
||||
generates_usage_data: null
|
||||
market: [EU]
|
||||
|
||||
transition_goal:
|
||||
from: [ISO9001]
|
||||
to:
|
||||
- target: CRA
|
||||
pattern: TP-ISO9001-CRA-v1
|
||||
- target: MaschinenVO
|
||||
pattern: null
|
||||
note: pattern_pending
|
||||
|
||||
expected_outcome:
|
||||
cra:
|
||||
pattern: TP-ISO9001-CRA-v1
|
||||
# A QMS gives only process discipline...
|
||||
expected_likely_covered_at_least:
|
||||
- document_and_change_control
|
||||
- supplier_evaluation
|
||||
- release_and_approval_process
|
||||
# ...so the CRA delta is LARGE — nearly the whole security set.
|
||||
expected_delta_at_least:
|
||||
- product_cyber_risk_assessment
|
||||
- secure_development_lifecycle
|
||||
- technical_vulnerability_management
|
||||
- coordinated_vulnerability_disclosure
|
||||
- sbom_creation
|
||||
- security_update_support_period
|
||||
- secure_signed_update_distribution
|
||||
- exploited_vuln_and_incident_reporting
|
||||
- ce_conformity_assessment_and_technical_documentation
|
||||
expected_delta_much_larger_than: RTS-001 # regression: ISO9001 leaves more open than ISO27001
|
||||
data_act:
|
||||
expectation: uncertain
|
||||
deciding_questions: [connected_product, generates_usage_data, data_act_scope]
|
||||
rationale: "Often not a connected product, but applicability is not assumed either way — the engine must ask."
|
||||
@@ -0,0 +1,54 @@
|
||||
# Reference Transition Scenario — ANONYMIZED ARCHETYPE ONLY (no real company names stored).
|
||||
id: RTS-003
|
||||
archetype: "Machine builder with an ISMS and networked products — connected machines that may generate usage data"
|
||||
note: "Anonymized typical starting situation; illustrative only. Highlights the Data-Act uncertainty."
|
||||
|
||||
reference_company:
|
||||
sector: mechanical_engineering
|
||||
known_certifications: [ISO27001] # ISMS ~ ISO 27001
|
||||
product_traits:
|
||||
is_machine: true
|
||||
is_component: false
|
||||
has_embedded_software: true
|
||||
connected_to_internet: true
|
||||
has_remote_access: true
|
||||
generates_usage_data: null # UNKNOWN -> the Data-Act deciding question
|
||||
market: [EU]
|
||||
|
||||
transition_goal:
|
||||
from: [ISO27001]
|
||||
to:
|
||||
- target: CRA
|
||||
pattern: TP-ISO27001-CRA-v1
|
||||
- target: MaschinenVO
|
||||
pattern: null
|
||||
note: pattern_pending
|
||||
- target: DataAct
|
||||
pattern: null
|
||||
note: uncertain_hypothesis # NOT asserted — see expected_outcome.data_act
|
||||
|
||||
expected_outcome:
|
||||
cra:
|
||||
pattern: TP-ISO27001-CRA-v1
|
||||
expected_likely_covered_at_least:
|
||||
- incident_management
|
||||
- technical_vulnerability_management
|
||||
- secure_development_lifecycle
|
||||
- access_control_and_authentication
|
||||
- security_logging_and_monitoring
|
||||
expected_delta_at_least:
|
||||
- sbom_creation
|
||||
- coordinated_vulnerability_disclosure
|
||||
- security_update_support_period
|
||||
- secure_signed_update_distribution
|
||||
- exploited_vuln_and_incident_reporting
|
||||
- product_cyber_risk_assessment
|
||||
- ce_conformity_assessment_and_technical_documentation
|
||||
data_act:
|
||||
expectation: uncertain # the core correction: a connected machine MAY fall under the Data Act
|
||||
deciding_questions: [generates_usage_data, connected_product, data_act_scope]
|
||||
rationale: >
|
||||
A networked machine is MORE likely to fall under the Data Act than a pure component, but it is NOT
|
||||
a settled fact — it depends on usage-data generation, user access, and scope. The Reference Suite
|
||||
checks that the engine recognises the RIGHT uncertainty and asks the deciding question, NOT that it
|
||||
writes a fixed gilt/gilt-nicht.
|
||||
+95
@@ -0,0 +1,95 @@
|
||||
# Transition KNOWLEDGE Pattern (TKP) — ISO 9001 (QMS) -> CRA (Reg. (EU) 2024/2847)
|
||||
# Curated regulatory KNOWLEDGE. Different character again: ISO 9001 gives PROCESS discipline
|
||||
# (document/change control, supplier evaluation, release approval) but almost NOTHING product-cyber.
|
||||
# Therefore the CRA delta is LARGE — the opposite shape of ISMS->TISAX. Used by RTS-002.
|
||||
|
||||
id: TP-ISO9001-CRA-v1
|
||||
status: draft # levels: draft(L1) -> reviewed(L2) -> validated(L3, expert) -> proven(L4)
|
||||
version: 1
|
||||
|
||||
transition_goal:
|
||||
from:
|
||||
standard: "ISO 9001"
|
||||
edition: "2015"
|
||||
nature: organizational_qms
|
||||
to:
|
||||
regulation: "Cyber Resilience Act"
|
||||
reference: "Regulation (EU) 2024/2847"
|
||||
applies_from: "2027-12-11"
|
||||
nature: product_cybersecurity
|
||||
one_line: "Move a manufacturer whose only management system is a QMS toward CRA conformity for a product with digital elements."
|
||||
|
||||
provenance:
|
||||
author: "Claude (Reasoning session) — AI first draft (L1)"
|
||||
basis: "ISO 9001:2015 (7.5 documented information, 8.4 external providers, 8.5.6 control of changes, 8.6 release) vs CRA Annex I."
|
||||
reviewed_by: null
|
||||
reviewed_at: null
|
||||
validated_by: null
|
||||
|
||||
disclaimer: >
|
||||
Curated expert knowledge, NOT a normative proof. KEY INSIGHT: ISO 9001 is a QUALITY management
|
||||
system — it provides process discipline but no information-security or product-cybersecurity
|
||||
capability. The CRA delta for an ISO-9001-only manufacturer is therefore LARGE (nearly the whole
|
||||
CRA security + vulnerability-handling + conformity set). Welt-1; confidence from the curated relationship.
|
||||
|
||||
source_state_variants:
|
||||
certified: "ISO 9001 certified -> the process-discipline assumptions hold; security substance is still missing."
|
||||
qms_introduced: "QMS implemented but not certified -> downgrade 'partially_supports' to needs_confirmation."
|
||||
|
||||
# ── A) LIKELY COVERED — only process discipline (partially_supports), NOT security. ──
|
||||
likely_covered:
|
||||
- capability: document_and_change_control
|
||||
iso9001_basis: ["7.5", "8.5.6"]
|
||||
cra_target: [Annex_VII_technical_documentation, Annex_I_Part_II_2_updates]
|
||||
relationship: partially_supports
|
||||
confidence_source: relationship
|
||||
verification: required
|
||||
expected_evidence: [document_control_procedure]
|
||||
rationale: "ISO 9001 document/change control gives the discipline to MAINTAIN technical documentation and controlled updates — but no security content. Hence 'partially_supports'."
|
||||
reviewable_claim: "Document/change control helps maintain CRA technical documentation but does not produce it."
|
||||
|
||||
- capability: supplier_evaluation
|
||||
iso9001_basis: ["8.4"]
|
||||
cra_target: [Annex_I_Part_II_1_components]
|
||||
relationship: partially_supports
|
||||
confidence_source: relationship
|
||||
verification: required
|
||||
expected_evidence: [supplier_evaluation_records]
|
||||
rationale: "Supplier evaluation gives a basis for supply-chain control — but ISO 9001 evaluates QUALITY, not security/components. Hence 'partially_supports'."
|
||||
reviewable_claim: "Quality supplier evaluation does not establish component security or an SBOM."
|
||||
|
||||
- capability: release_and_approval_process
|
||||
iso9001_basis: ["8.6"]
|
||||
cra_target: [Annex_I_Part_II_8_distribution]
|
||||
relationship: partially_supports
|
||||
confidence_source: relationship
|
||||
verification: required
|
||||
expected_evidence: [release_procedure]
|
||||
rationale: "A release/approval gate gives release discipline — but not secure, signed update distribution. Hence 'partially_supports'."
|
||||
reviewable_claim: "A quality release gate does not establish signed secure update distribution."
|
||||
|
||||
# ── B) DELTA — nearly the whole CRA security + vulnerability-handling + conformity set. ──
|
||||
delta_requirements:
|
||||
- {capability: product_cyber_risk_assessment, cra_basis: "Annex I + technical documentation", missing_because: "ISO 9001 has no security risk assessment.", why_asked: "The CRA needs a product cyber risk assessment; a QMS has none.", dropped_if: ["A product cyber risk assessment exists."], needed_information: verify_existence, expected_evidence: [product_risk_assessment], priority: high, reviewable_claim: "ISO 9001 establishes no product cyber risk assessment."}
|
||||
- {capability: secure_development_lifecycle, cra_basis: "Annex I Part I (1), Part II (3)", missing_because: "ISO 9001 has no secure development.", why_asked: "The CRA requires secure-by-design development + security testing; a QMS does not address security.", dropped_if: ["A documented secure development lifecycle exists."], needed_information: verify_existence, expected_evidence: [secure_development_policy], priority: high, reviewable_claim: "ISO 9001 does not establish a secure development lifecycle."}
|
||||
- {capability: technical_vulnerability_management, cra_basis: "Annex I Part II (2)", missing_because: "ISO 9001 has no vulnerability management.", why_asked: "The CRA requires handling product vulnerabilities; a QMS has no such process.", dropped_if: ["A vulnerability management process exists."], needed_information: verify_existence, expected_evidence: [vulnerability_management_procedure], priority: high, reviewable_claim: "ISO 9001 does not establish vulnerability management."}
|
||||
- {capability: coordinated_vulnerability_disclosure, cra_basis: "Annex I Part II (5,6)", missing_because: "No CVD in a QMS.", why_asked: "The CRA requires a way to receive product vulnerability reports (CVD/PSIRT).", dropped_if: ["A published CVD policy + contact exists."], needed_information: verify_existence, expected_evidence: [cvd_policy], priority: high, reviewable_claim: "ISO 9001 does not establish coordinated vulnerability disclosure."}
|
||||
- {capability: sbom_creation, cra_basis: "Annex I Part II (1)", missing_because: "No SBOM in a QMS.", why_asked: "The CRA requires a software bill of materials.", dropped_if: ["A machine-readable SBOM is produced per release."], needed_information: determine_sbom_maturity, expected_evidence: [sbom], priority: high, reviewable_claim: "ISO 9001 does not produce an SBOM."}
|
||||
- {capability: security_update_support_period, cra_basis: "Art. 13(8) + Annex I", missing_because: "No support period in a QMS.", why_asked: "The CRA requires a defined security-update support period.", dropped_if: ["A product support/lifecycle policy defines the period."], needed_information: determine_duration, expected_evidence: [support_policy], priority: high, reviewable_claim: "ISO 9001 does not define a security-update support period."}
|
||||
- {capability: secure_signed_update_distribution, cra_basis: "Annex I Part II (8)", missing_because: "No signed updates in a QMS.", why_asked: "The CRA requires authenticity/integrity-protected updates.", dropped_if: ["Updates are cryptographically signed and verified."], needed_information: verify_existence, expected_evidence: [config_export], priority: high, reviewable_claim: "ISO 9001 does not establish signed update distribution."}
|
||||
- {capability: exploited_vuln_and_incident_reporting, cra_basis: "Art. 14", missing_because: "No Art. 14 reporting in a QMS.", why_asked: "The CRA imposes 24h/72h reporting of exploited vulnerabilities to authorities.", dropped_if: ["A documented Art. 14 reporting procedure exists."], needed_information: verify_existence, expected_evidence: [reporting_procedure], priority: high, reviewable_claim: "ISO 9001 does not establish CRA Art. 14 reporting."}
|
||||
- {capability: access_control_and_authentication, cra_basis: "Annex I Part I (4)", missing_because: "No security access control in a QMS.", why_asked: "The CRA requires product authentication / no default credentials.", dropped_if: ["Product authentication is documented + tested."], needed_information: verify_existence, expected_evidence: [access_control_policy], priority: medium, reviewable_claim: "ISO 9001 does not establish product authentication."}
|
||||
- {capability: ce_conformity_assessment_and_technical_documentation, cra_basis: "Annex VII + CE", missing_because: "No CRA conformity in a QMS.", why_asked: "CRA conformity needs a product conformity assessment + CE + technical documentation + DoC.", dropped_if: ["A CRA conformity assessment + technical documentation exist."], needed_information: request_evidence, expected_evidence: [technical_documentation, declaration_of_conformity], priority: high, reviewable_claim: "ISO 9001 does not satisfy CRA conformity assessment."}
|
||||
|
||||
rejected_assumptions:
|
||||
- "ISO 9001 does NOT establish information security or product cybersecurity."
|
||||
- "ISO 9001 does NOT establish secure development, vulnerability management, SBOM, CVD, or Art. 14 reporting."
|
||||
- "An ISO 9001 certificate does NOT satisfy CRA conformity assessment."
|
||||
|
||||
determinism_goal: >
|
||||
Two independent auditors should agree that an ISO-9001-only manufacturer needs almost the whole CRA
|
||||
security set; the QMS reduces effort only on documentation/change/release discipline.
|
||||
|
||||
review_checklist:
|
||||
- "Confirm the (deliberately large) delta with a CRA expert."
|
||||
- "Replace capability ids with Capability Registry MCAP ids once assigned."
|
||||
Reference in New Issue
Block a user