From 0da093c046c493364d705d38ee5f37a6316c44d6 Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Sat, 27 Jun 2026 08:29:30 +0200 Subject: [PATCH] docs(knowledge): TKP 4-level lifecycle + 3 enrichments + ISMS->TISAX (genericity proof) Transition KNOWLEDGE Patterns (renamed term -- curated knowledge, not an algorithm): - 4 maturity levels: draft -> reviewed -> validated (domain expert) -> proven (field). "approved" dropped; target is validated. TP-ISO27001-CRA set to reviewed (L2). - 3 enrichments per pattern: confidence_source: relationship (curated, not an LLM estimate -> computed-not-stored); why_asked (customer-facing: why the source does not suffice here); dropped_if (what makes the question unnecessary). Applied to TP-ISO27001-CRA. - New TP-ISMS-TISAX (draft): different character -- info-security module mostly covered; delta is automotive-specific (prototype protection, TISAX labels, VDA ISA self-assessment, ENX assessment, Art. 28 data protection). Proves the architecture is GENERIC, not CRA-tailored. - Reference scenario 4 generalized to loop over ALL patterns through RS-005: both carried (CRA 17->17, TISAX 13->13) -> a living genericity + regression test for every future pattern. Non-runtime knowledge + reference harness -> no deploy (ADR-001). Next: ISO9001->IATF16949. Co-Authored-By: Claude Opus 4.7 --- .../knowledge/transition_patterns/README.md | 77 ++++--- .../transition_pattern_isms_to_tisax_v1.yaml | 191 ++++++++++++++++++ ...transition_pattern_iso27001_to_cra_v1.yaml | 61 ++++-- .../reference_scenarios/generate.py | 80 ++++---- .../reference_scenario_suite_v1.md | 42 ++-- 5 files changed, 329 insertions(+), 122 deletions(-) create mode 100644 backend-compliance/knowledge/transition_patterns/transition_pattern_isms_to_tisax_v1.yaml diff --git a/backend-compliance/knowledge/transition_patterns/README.md b/backend-compliance/knowledge/transition_patterns/README.md index 26369eac..8afe1fa1 100644 --- a/backend-compliance/knowledge/transition_patterns/README.md +++ b/backend-compliance/knowledge/transition_patterns/README.md @@ -1,54 +1,65 @@ -# Transition Patterns — curated knowledge base +# Transition Knowledge Patterns (TKP) — curated knowledge base -**Knowledge, not runtime code.** This directory holds the Reasoning session's *Knowledge -Acquisition* output: versioned, reviewed expert patterns that describe how to move a company -from an **Ausgangszustand** (e.g. ISO 27001) to a regulatory **Zielzustand** (e.g. CRA). +**Curated regulatory KNOWLEDGE in machine-readable form — not an algorithm, not runtime code.** +This directory holds the Reasoning session's *Knowledge Acquisition* output: versioned, +expert-reviewed patterns describing how to move a company from an **Ausgangszustand** +(e.g. ISO 27001) to a regulatory **Zielzustand** (e.g. CRA). -Nothing imports these at runtime today — they are consumed later by the Transition Planning -Engine (`compliance/transition_reasoning/`, RS-005) and the Question Renderer (RS-005.1). -Adding/curating a pattern is therefore **non-runtime → no deploy** (see ADR-001). +Nothing imports these at runtime — they are consumed later by the Transition Planning Engine +(`compliance/transition_reasoning/`, RS-005) and the Question Renderer (RS-005.1). Adding or +curating a pattern is therefore **non-runtime → no deploy** (ADR-001). + +## Maturity levels (replace draft → reviewed → "approved") + +| Level | `status` | Meaning | +|---|---|---| +| 1 | `draft` | AI first draft; no human review. | +| 2 | `reviewed` | Internally reviewed by BreakPilot: architecture consistent, no obvious contradictions, references plausible, reference scenario runs. | +| 3 | `validated` | At least one **domain expert** (e.g. ISO 27001 lead auditor / CRA expert) checked it; all `review_required` points closed. | +| 4 | `proven` | Applied in **multiple real customer projects**; the delta questions proved correct and sufficient; feedback incorporated. | + +"approved" is intentionally NOT used — the target is **validated** (expert-checked), then **proven** (field-tested). ## Why patterns instead of a question list -A pattern captures the **difference** between two states, not a full standard. It separates: -- `likely_covered_org_level` — what the source state probably already establishes (Welt 1 hint, - needs product-level confirmation; never auto-"erfüllt"); -- `delta_requirements` — what the target state adds that the source has no analogue for (ask first). +A pattern captures the **difference** between two states, not a full standard: +- `likely_covered` — what the source state probably already establishes (Welt-1 hint, needs + product-level confirmation; never auto-"erfüllt"); +- `delta_requirements` — what the target adds that the source has no analogue for (ask first). After ~5 patterns the repeated delta items converge into **Master Delta Questions** — emergent, -not designed up front (the same identity-machine discipline as Master Controls/Obligations/Capabilities). +not designed up front (the identity-machine discipline of Master Controls/Obligations/Capabilities). ## File schema (per `transition_pattern__to__v.yaml`) -`id` · `status` (draft → reviewed → approved) · `version` · -`transition_goal` ({from: standard/edition/nature, to: regulation/reference/applies_from/nature, one_line}) · -`provenance` (author/basis/reviewed_by/reviewed_at) · `disclaimer` · -`source_state_variants` (certified / isms_introduced / expired / limited_scope — how the start changes assumption strength) · -`likely_covered[]` ({capability, source_basis, target, **relationship** (supports|partially_supports, never equivalent), -**verification** (required), expected_evidence, **rationale** (the *Warum* — why this relationship), **reviewable_claim** -(an auditor can agree/disagree)}) · -`delta_requirements[]` ({capability, target_basis, **missing_because**, needed_information (intent), -expected_evidence, priority, **reviewable_claim**}) · -`rejected_assumptions[]` (explicit "does NOT establish …") · `determinism_goal` · `review_checklist[]`. +`id` · `status` (4 levels above) · `version` · `transition_goal` · `provenance` · `disclaimer` · +`source_state_variants` · `likely_covered[]` · `delta_requirements[]` · `rejected_assumptions[]` · +`determinism_goal` · `review_checklist[]`. -**Gold-standard bar:** every line is auditor-checkable (agree/disagree, not "probably"); each assumption -carries a typed `relationship` + a `rationale`; each delta maps to a missing capability + needed info; -explicit `rejected_assumptions` keep the source certificate from being over-read; two auditors should -arrive at the same delta questions (`determinism_goal`). +**`likely_covered[]`** item: `{capability, source_basis, target, relationship` (supports|partially_supports, +never equivalent)`, verification` (required)`, confidence_source` (**relationship** — NOT an LLM estimate; +fits *computed-not-stored*)`, expected_evidence, rationale` (the *Warum*)`, reviewable_claim}`. + +**`delta_requirements[]`** item: `{capability, target_basis, missing_because, why_asked` (customer-facing: +why the source does NOT suffice here → why BreakPilot asks)`, dropped_if` (what makes the question +unnecessary — e.g. a named document/process)`, needed_information` (intent)`, expected_evidence, priority, +reviewable_claim}`. ## Hard rules -- **Expert draft, not a normative/legal proof.** A pattern is a consultant-grade heuristic; it must - be reviewed (and ideally auditor-checked) before customer use. `status` tracks that. +- **Expert knowledge, not a normative/legal proof.** A pattern is a consultant-grade heuristic; it must + reach `validated` (expert-checked) before customer use. `status` tracks this. - **Welt-1 only.** „probably covered" is a hint with confidence + verification need, never „erfüllt". -- `question_intent` is an intent (verify_existence / determine_duration / request_evidence / …) — the - rendered question text is produced later by RS-005.1, not stored here. +- **Confidence comes from the curated `relationship`, not a model** (`confidence_source: relationship`). +- `question_intent` is an intent (verify_existence / determine_duration / …); the rendered question text + is produced later by RS-005.1, not stored here. - `capability` ids reference the (Execution-owned) Capability Registry MCAP ids once assigned. ## Catalogue -| Pattern | from → to | status | +| Pattern | from → to | status (level) | |---|---|---| -| `transition_pattern_iso27001_to_cra_v1.yaml` | ISO 27001 → CRA | draft | +| `transition_pattern_iso27001_to_cra_v1.yaml` | ISO 27001 → CRA | `reviewed` (L2) | +| `transition_pattern_isms_to_tisax_v1.yaml` | ISMS → TISAX | `draft` (L1) | -Next candidates: `ISMS → TISAX`, `ISO 9001 → IATF 16949`, `ISO 14001 → CRA-Environmental`. +Next candidates: `ISO 9001 → IATF 16949`, `ISO 14001 → environmental regulation`. diff --git a/backend-compliance/knowledge/transition_patterns/transition_pattern_isms_to_tisax_v1.yaml b/backend-compliance/knowledge/transition_patterns/transition_pattern_isms_to_tisax_v1.yaml new file mode 100644 index 00000000..32b2bc56 --- /dev/null +++ b/backend-compliance/knowledge/transition_patterns/transition_pattern_isms_to_tisax_v1.yaml @@ -0,0 +1,191 @@ +# Transition KNOWLEDGE Pattern (TKP) — ISMS / ISO 27001 -> TISAX (VDA ISA, ENX) +# Curated regulatory KNOWLEDGE in machine-readable form (not an algorithm, not runtime code). +# Different CHARACTER than ISO27001->CRA: most information-security requirements are likely covered; +# the delta is narrow + automotive-specific (prototype protection, labels, the TISAX assessment process). +# This is the genericity proof for the Transition-Knowledge architecture (not CRA-tailored). + +id: TP-ISMS-TISAX-v1 +status: draft # levels: draft(L1) -> reviewed(L2) -> validated(L3, expert) -> proven(L4, field) +version: 1 + +transition_goal: + from: + standard: "ISO/IEC 27001" + edition: "2022" + nature: organizational_isms + to: + framework: "TISAX" + reference: "VDA ISA (Information Security Assessment), exchanged via ENX" + nature: automotive_supply_chain_infosec + one_line: "Move an organization with an ISMS toward a TISAX label for the automotive supply chain." + +provenance: + author: "Claude (Reasoning session) — AI first draft (L1)" + basis: "ISO/IEC 27001:2022 Annex A vs VDA ISA catalogue (Information Security module ~ ISO 27001; plus Prototype Protection and Data Protection modules) + the TISAX assessment/label process via ENX." + reviewed_by: null + reviewed_at: null + validated_by: null + +disclaimer: > + Curated expert knowledge, NOT a normative proof. KEY INSIGHT: TISAX's Information-Security module + largely OVERLAPS a mature ISO 27001 ISMS — so most is 'supports'. The delta is narrow and + AUTOMOTIVE-specific (prototype protection, the TISAX label scope, and the assessment/exchange process + itself). Every assumption is Welt-1; confidence comes from the curated relationship, not a model. + +source_state_variants: + certified: "ISO 27001 valid + scope covers the relevant sites/teams -> the info-security assumptions hold." + isms_introduced: "ISMS implemented but not certified -> downgrade 'supports' to needs_confirmation; TISAX assessment levels (AL2/AL3) demand evidence depth." + expired: "Certificate lapsed -> re-verify." + limited_scope: "Certified scope excludes the site/team in TISAX scope -> assumptions do NOT transfer for that scope." + +# ── A) LIKELY COVERED — TISAX Information-Security module ~ ISO 27001 (mostly 'supports'). ── +likely_covered: + - capability: information_security_management + iso27001_basis: [Clause_4_10, A.5.1] + tisax_target: [VDA_ISA_information_security] + relationship: supports + confidence_source: relationship + verification: required + expected_evidence: [isms_documentation] + rationale: "A certified ISMS IS the backbone of the TISAX information-security module. Still 'supports', because TISAX may require a higher assessment level (AL2/AL3) and site-specific evidence." + reviewable_claim: "An ISO 27001 ISMS strongly covers the TISAX information-security module but does not by itself grant a label." + + - capability: access_control_and_authentication + iso27001_basis: [A.5.15, A.5.16, A.5.17, A.5.18, A.8.5] + tisax_target: [VDA_ISA_information_security] + relationship: supports + confidence_source: relationship + verification: required + expected_evidence: [access_control_policy] + rationale: "Directly mapped between ISO 27001 and the VDA ISA info-security controls. Hence 'supports'." + reviewable_claim: "Access control maps closely; confirm it covers the TISAX assessment scope." + + - capability: asset_and_configuration_management + iso27001_basis: [A.5.9, A.5.10, A.5.11, A.8.9] + tisax_target: [VDA_ISA_information_security] + relationship: supports + confidence_source: relationship + verification: required + expected_evidence: [asset_inventory] + rationale: "Asset management maps between ISO 27001 and VDA ISA. Hence 'supports'." + reviewable_claim: "Asset management maps closely to the TISAX info-security module." + + - capability: incident_management + iso27001_basis: [A.5.24, A.5.25, A.5.26, A.5.27, A.5.28] + tisax_target: [VDA_ISA_information_security] + relationship: supports + confidence_source: relationship + verification: required + expected_evidence: [incident_response_procedure] + rationale: "Incident management maps between ISO 27001 and VDA ISA. Hence 'supports'." + reviewable_claim: "Incident management maps closely to the TISAX info-security module." + + - capability: supplier_security + iso27001_basis: [A.5.19, A.5.20, A.5.21, A.5.22] + tisax_target: [VDA_ISA_information_security] + relationship: supports + confidence_source: relationship + verification: required + expected_evidence: [supplier_security_policy] + rationale: "Supplier security maps; TISAX adds expectations for connections to OEMs (delta below)." + reviewable_claim: "Supplier security maps; OEM connection specifics are a delta item." + + - capability: cryptography + iso27001_basis: [A.8.24] + tisax_target: [VDA_ISA_information_security] + relationship: supports + confidence_source: relationship + verification: required + expected_evidence: [cryptography_policy] + rationale: "Cryptography maps between ISO 27001 and VDA ISA. Hence 'supports'." + reviewable_claim: "Cryptography maps closely to the TISAX info-security module." + + - capability: physical_security + iso27001_basis: [A.7.1, A.7.2, A.7.3, A.7.4] + tisax_target: [VDA_ISA_information_security] + relationship: partially_supports + confidence_source: relationship + verification: required + expected_evidence: [physical_security_concept] + rationale: "General physical security maps; but TISAX prototype protection demands STRICTER, dedicated physical zones (delta). Hence 'partially_supports'." + reviewable_claim: "General physical security maps, but does not meet prototype-protection zoning." + + - capability: security_awareness_training + iso27001_basis: [A.6.3] + tisax_target: [VDA_ISA_information_security] + relationship: supports + confidence_source: relationship + verification: required + expected_evidence: [training_records] + rationale: "Awareness/training maps between ISO 27001 and VDA ISA. Hence 'supports'." + reviewable_claim: "Awareness training maps closely to the TISAX info-security module." + +# ── B) DELTA — TISAX-specific, NO (or only partial) ISO 27001 analogue. ask first. ── +delta_requirements: + - capability: prototype_protection + tisax_basis: "VDA ISA — Prototype Protection module (physical + logical protection of prototype vehicles/components/parts)." + missing_because: "ISO 27001 has no dedicated prototype-protection requirement." + why_asked: "TISAX (for proto labels) requires dedicated physical/logical protection of prototypes — secure zones, access logging, photography bans, test-drive rules; an ISMS does not cover this." + dropped_if: ["A documented prototype-protection concept with dedicated zones + access control exists.", "The TISAX scope does NOT include a prototype label."] + needed_information: verify_existence + expected_evidence: [prototype_protection_concept] + priority: high + reviewable_claim: "An ISO-27001-only organization typically has no automotive prototype-protection regime." + + - capability: tisax_label_scope_selection + tisax_basis: "TISAX assessment objectives / labels (e.g. info-high, info-very-high, proto-parts, proto-vehicles, data)." + missing_because: "ISO 27001 has no concept of TISAX labels/assessment objectives." + why_asked: "TISAX requires you to choose the assessment objectives (labels) your OEM customers demand; this determines which modules apply." + dropped_if: ["The required TISAX labels are defined (with the customer's demand) and documented."] + needed_information: request_evidence + expected_evidence: [tisax_scope_definition] + priority: high + reviewable_claim: "An ISMS does not define TISAX assessment objectives/labels." + + - capability: vda_isa_self_assessment + tisax_basis: "VDA ISA self-assessment completed before the assessment." + missing_because: "The VDA ISA catalogue self-assessment is TISAX-specific." + why_asked: "TISAX requires a completed VDA ISA self-assessment; an ISO 27001 Statement of Applicability is not the same artefact." + dropped_if: ["A current VDA ISA self-assessment (matching the chosen labels) is completed."] + needed_information: verify_existence + expected_evidence: [vda_isa_self_assessment] + priority: high + reviewable_claim: "An ISO 27001 SoA is not a VDA ISA self-assessment." + + - capability: data_protection_processing_on_behalf + tisax_basis: "VDA ISA — Data Protection module (Art. 28 GDPR processing on behalf), if a 'data' label is in scope." + missing_because: "ISO 27001 is not a data-protection standard." + why_asked: "If a TISAX data label is in scope, you must show Art. 28 GDPR processing-on-behalf controls; ISO 27001 does not establish these." + dropped_if: ["No data label is in scope.", "Art. 28 GDPR processing-on-behalf controls + TOMs are documented."] + needed_information: verify_existence + expected_evidence: [data_processing_agreement, toms] + priority: medium + reviewable_claim: "ISO 27001 does not by itself establish Art. 28 GDPR processing-on-behalf controls." + + - capability: tisax_assessment_via_enx + tisax_basis: "TISAX process: registration on the ENX portal, assessment by an approved audit provider, label exchange via ENX." + missing_because: "The TISAX assessment/exchange process has no ISO 27001 analogue." + why_asked: "A TISAX label is obtained via a specific process (ENX registration + approved audit provider + label exchange); ISO 27001 certification does not produce a TISAX label." + dropped_if: ["A TISAX assessment with an approved audit provider is scheduled/completed and registered on ENX."] + needed_information: verify_existence + expected_evidence: [tisax_assessment_report] + priority: high + reviewable_claim: "ISO 27001 certification does not produce a TISAX label." + +# ── C) Explicit rejections. ── +rejected_assumptions: + - "ISO 27001 does NOT establish automotive prototype protection." + - "ISO 27001 does NOT define TISAX labels / assessment objectives." + - "ISO 27001 does NOT constitute a VDA ISA self-assessment." + - "ISO 27001 certification does NOT produce a TISAX label (separate ENX assessment required)." + - "ISO 27001 does NOT by itself satisfy the Data-Protection module (Art. 28 GDPR) if a data label is in scope." + +determinism_goal: > + Two independent TISAX/ISO 27001 assessors reading this pattern should arrive at the SAME set of delta + questions for the same organization + chosen labels. If not, the pattern is not yet validated. + +review_checklist: + - "Confirm the VDA ISA module mapping (Information Security / Prototype Protection / Data Protection) with a TISAX assessor before customer use." + - "Confirm prototype-protection requirements against the current VDA ISA edition." + - "Replace capability ids with the Capability Registry MCAP ids once assigned (placeholders here)." + - "Confirm which assumptions are level-dependent (AL2 vs AL3)." diff --git a/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml b/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml index 1e8f26c8..7004389b 100644 --- a/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml +++ b/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml @@ -1,9 +1,9 @@ -# Transition Pattern — ISO/IEC 27001 (ISMS) -> CRA (Cyber Resilience Act, Reg. (EU) 2024/2847) -# GOLD-STANDARD structure (the template all future patterns adopt). Curated expert knowledge, -# NOT runtime code. Consumed later by the Transition Planning Engine (RS-005) and Renderer (RS-005.1). +# Transition KNOWLEDGE Pattern (TKP) — ISO/IEC 27001 (ISMS) -> CRA (Reg. (EU) 2024/2847) +# Curated regulatory KNOWLEDGE in machine-readable form (not an algorithm, not runtime code). +# Gold-standard template; consumed later by the Transition Planning Engine (RS-005) + Renderer (RS-005.1). id: TP-ISO27001-CRA-v1 -status: draft # draft -> reviewed -> approved (auditor review pending) +status: reviewed # levels: draft(L1) -> reviewed(L2) -> validated(L3, expert) -> proven(L4, field) version: 1 transition_goal: @@ -14,37 +14,36 @@ transition_goal: to: regulation: "Cyber Resilience Act" reference: "Regulation (EU) 2024/2847" - applies_from: "2027-12-11" # main obligations + applies_from: "2027-12-11" nature: product_cybersecurity one_line: "Move a manufacturer with a certified ISMS toward CRA conformity for a product with digital elements." provenance: - author: "Claude (Reasoning session) — first expert draft, gold-standard structure" + author: "Claude (Reasoning session) — AI first draft, internally reviewed (L2)" basis: "ISO/IEC 27001:2022 Annex A vs CRA Annex I (Part I security requirements, Part II vulnerability handling), Art. 13 (support period), Art. 14 (reporting), conformity assessment + CE + technical documentation (Annex VII)." - reviewed_by: null + reviewed_by: "BreakPilot (internal, architecture + structure)" reviewed_at: null + validated_by: null # domain expert (ISO 27001 lead auditor / CRA expert) — pending disclaimer: > - Expert DRAFT, not a normative or legal proof. KEY ASYMMETRY: ISO 27001 is ORGANIZATIONAL (an ISMS); - the CRA is PRODUCT-level. Every assumption below is Welt-1 — a hint that requires PRODUCT-level - evidence, never automatically "erfüllt". Each line is phrased so an auditor can explicitly AGREE or - DISAGREE (not "probably"). + Curated expert knowledge, NOT a normative or legal proof. KEY INSIGHT (drives ~80% of decisions): + ISO 27001 is ORGANIZATIONAL (an ISMS); the CRA is PRODUCT-level. Every assumption is Welt-1 — a hint + needing PRODUCT-level evidence, never automatically "erfüllt". Confidence comes from the curated + relationship, not a model estimate. Each line is phrased so an auditor can AGREE or DISAGREE. -# How the starting point changes how strongly the assumptions transfer. source_state_variants: certified: "ISO 27001 certificate valid AND scope covers the product's development/operations -> assumptions hold at the stated relationship." isms_introduced: "ISMS implemented but not certified -> downgrade every 'supports' to needs_confirmation." expired: "Certificate lapsed -> re-verify; treat all assumptions as needs_confirmation." limited_scope: "Certified scope excludes the product or its dev unit -> assumptions do NOT transfer; treat as missing until scope is confirmed." -# ── A) LIKELY COVERED (org level). relationship + verification + rationale + reviewable claim. ── -# relationship vocabulary aligns with the Capability Registry (2C): supports | partially_supports -# (never "equivalent" here — an org control is never product-equivalent on its own). +# ── A) LIKELY COVERED (org level). relationship + confidence_source + verification + rationale. ── likely_covered: - capability: incident_management iso27001_basis: [A.5.24, A.5.25, A.5.26, A.5.27, A.5.28] cra_target: [Annex_I_Part_II, Art_14_reporting] relationship: supports + confidence_source: relationship # curated, NOT an LLM estimate (computed-not-stored) verification: required expected_evidence: [incident_response_procedure] rationale: "ISO 27001 covers ORGANIZATIONAL incident management; the CRA additionally demands PRODUCT vulnerability handling and statutory reporting to CSIRT/ENISA. Hence 'supports', not 'equivalent'." @@ -54,6 +53,7 @@ likely_covered: iso27001_basis: [A.8.8] cra_target: [Annex_I_Part_II_2] relationship: supports + confidence_source: relationship verification: required expected_evidence: [vulnerability_management_procedure] rationale: "Internal vulnerability management exists; the CRA needs a PRODUCT-facing process (PSIRT, coordinated disclosure). Hence 'supports'." @@ -63,6 +63,7 @@ likely_covered: iso27001_basis: [A.5.19, A.5.20, A.5.21, A.5.22] cra_target: [Annex_I_Part_II_1_components] relationship: supports + confidence_source: relationship verification: required expected_evidence: [supplier_security_policy] rationale: "Supplier security exists; the CRA needs component-level transparency (SBOM) and tracking third-party/OSS vulnerabilities. Hence 'supports'." @@ -72,6 +73,7 @@ likely_covered: iso27001_basis: [A.5.15, A.5.16, A.5.17, A.5.18, A.8.5] cra_target: [Annex_I_Part_I_4] relationship: supports + confidence_source: relationship verification: required expected_evidence: [access_control_policy] rationale: "Org access control is mature; the CRA needs product authentication and no default credentials. Hence 'supports'." @@ -81,6 +83,7 @@ likely_covered: iso27001_basis: [A.8.24] cra_target: [Annex_I_Part_I_5, Annex_I_Part_I_6] relationship: partially_supports + confidence_source: relationship verification: required expected_evidence: [cryptography_policy] rationale: "A crypto policy exists; whether the PRODUCT actually encrypts data and protects integrity is unproven. Hence 'partially_supports'." @@ -90,6 +93,7 @@ likely_covered: iso27001_basis: [A.8.15, A.8.16] cra_target: [Annex_I_Part_I_12] relationship: supports + confidence_source: relationship verification: required expected_evidence: [logging_concept] rationale: "Org logging exists; the CRA needs security-relevant events recorded ON the product (with opt-out). Hence 'supports'." @@ -99,6 +103,7 @@ likely_covered: iso27001_basis: [A.8.25, A.8.27, A.8.28, A.8.29] cra_target: [Annex_I_Part_I_1, Annex_I_Part_II_3] relationship: supports + confidence_source: relationship verification: required expected_evidence: [secure_development_policy] rationale: "Secure development exists; the CRA needs demonstrated secure-by-design product properties + regular product security tests. Hence 'supports'." @@ -108,17 +113,21 @@ likely_covered: iso27001_basis: [A.5.9, A.5.10, A.5.11, A.8.9] cra_target: [Annex_I_Part_II_1_SBOM] relationship: partially_supports + confidence_source: relationship verification: required expected_evidence: [asset_inventory] rationale: "Asset/config management UNDERPINS an SBOM but is not one. Hence 'partially_supports'; the SBOM itself is a delta item." reviewable_claim: "Asset/config management does NOT constitute an SBOM." # ── B) DELTA — CRA-specific, NO ISO 27001 analogue. missing for an ISO-only company; ask first. ── +# Each carries why_asked (customer-facing) + dropped_if (what makes the question unnecessary). delta_requirements: - capability: sbom_creation cra_basis: "Annex I, Part II (1) — document components incl. a software bill of materials." missing_because: "ISO 27001 contains no SBOM requirement." - needed_information: determine_sbom_maturity # enum: never / manual / automatic / continuous + why_asked: "ISO 27001 does not require a full software bill of materials for every shipped product, so we must check whether one exists." + dropped_if: ["A current machine-readable SBOM (e.g. CycloneDX/SPDX) is produced per product release."] + needed_information: determine_sbom_maturity # never / manual / automatic / continuous expected_evidence: [sbom] priority: high reviewable_claim: "An ISO-27001-only manufacturer typically has no SBOM." @@ -126,6 +135,8 @@ delta_requirements: - capability: security_update_support_period cra_basis: "Art. 13(8) support period (default >= 5 years) + Annex I Part I (3) / Part II (2,7)." missing_because: "ISO 27001 defines no product support period or update-provision duty." + why_asked: "The CRA requires a defined security-update support period (default >= 5 years); ISO 27001 says nothing about it." + dropped_if: ["A documented product support/lifecycle policy states the security-update period."] needed_information: determine_duration expected_evidence: [support_policy, product_lifecycle_policy] priority: high @@ -134,6 +145,8 @@ delta_requirements: - capability: secure_signed_update_distribution cra_basis: "Annex I, Part II (8) — disseminate updates securely (authenticity/integrity)." missing_because: "Signed PRODUCT update distribution is product-specific, beyond ISO integrity controls." + why_asked: "The CRA requires updates delivered with authenticity/integrity protection; ISO integrity controls are organizational, not product update signing." + dropped_if: ["Update packages are cryptographically signed and verified on the device (documented)."] needed_information: verify_existence expected_evidence: [config_export, test_report] priority: high @@ -142,6 +155,8 @@ delta_requirements: - capability: coordinated_vulnerability_disclosure cra_basis: "Annex I, Part II (5,6) — CVD policy + a reporting contact address." missing_because: "ISO vulnerability management is internal, not a product-facing CVD/PSIRT." + why_asked: "The CRA requires a way for external parties to report product vulnerabilities (CVD/PSIRT); an internal ISMS process does not provide this." + dropped_if: ["A published CVD policy + reporting contact exists.", "A documented PSIRT procedure is in place."] needed_information: verify_existence expected_evidence: [cvd_policy] priority: high @@ -150,6 +165,8 @@ delta_requirements: - capability: public_security_advisories cra_basis: "Annex I, Part II (4,7) — disclose fixed vulnerabilities; provide advisories." missing_because: "No ISO obligation to publish product security advisories." + why_asked: "The CRA expects fixed vulnerabilities to be disclosed via advisories; ISO 27001 has no such product-facing publication duty." + dropped_if: ["A documented security-advisory process publishes fixed product vulnerabilities."] needed_information: verify_existence expected_evidence: [advisory_process] priority: medium @@ -158,6 +175,8 @@ delta_requirements: - capability: exploited_vuln_and_incident_reporting cra_basis: "Art. 14 — report actively exploited vulnerabilities + severe incidents to CSIRT/ENISA (24h early warning, 72h notification, final report)." missing_because: "Statutory authority-reporting with fixed deadlines; no ISO 27001 analogue." + why_asked: "The CRA imposes statutory deadlines (24h/72h) to report exploited vulnerabilities to authorities; ISO 27001 has no such obligation." + dropped_if: ["A documented procedure maps the Art. 14 24h/72h reporting flow to a named responsible role."] needed_information: verify_existence expected_evidence: [reporting_procedure] priority: high @@ -166,6 +185,8 @@ delta_requirements: - capability: secure_by_default_no_default_credentials cra_basis: "Annex I, Part I (2,4) — secure default configuration; no default passwords." missing_because: "A product property, not an ISMS control." + why_asked: "The CRA requires the product to ship securely configured with no default passwords; this is a product property the ISMS does not guarantee." + dropped_if: ["A test report confirms secure-by-default config and forced credential change."] needed_information: verify_existence expected_evidence: [config_export, test_report] priority: medium @@ -174,6 +195,8 @@ delta_requirements: - capability: product_cyber_risk_assessment cra_basis: "Annex I + technical documentation — cybersecurity risk assessment OF THE PRODUCT." missing_because: "ISO 27001 risk assessment is organizational, not a product cyber risk assessment." + why_asked: "The CRA technical documentation requires a cybersecurity risk assessment of the PRODUCT; the ISMS risk assessment is organizational." + dropped_if: ["A product-specific cyber risk assessment is part of the technical documentation."] needed_information: verify_existence expected_evidence: [product_risk_assessment] priority: high @@ -182,6 +205,8 @@ delta_requirements: - capability: ce_conformity_assessment_and_technical_documentation cra_basis: "Conformity assessment + CE marking + EU Declaration of Conformity + technical documentation (Annex VII)." missing_because: "An ISO 27001 certificate is NOT a CRA conformity assessment." + why_asked: "CRA conformity requires a product conformity assessment, CE marking, a Declaration of Conformity and technical documentation; an ISO 27001 certificate does not provide these." + dropped_if: ["A CRA conformity assessment + technical documentation (Annex VII) + DoC exist for the product."] needed_information: request_evidence expected_evidence: [technical_documentation, declaration_of_conformity] priority: high @@ -198,10 +223,10 @@ rejected_assumptions: determinism_goal: > Two independent ISO 27001 lead auditors reading this pattern should arrive at the SAME set of delta - questions for the same product. If they do not, the pattern is not yet gold standard. + questions for the same product. If they do not, the pattern is not yet validated. review_checklist: - "Validate every CRA Annex/Article reference with counsel before customer use (indicative here)." - "Replace capability ids with the Capability Registry MCAP ids once assigned (placeholders here)." - - "Have an ISO 27001 lead auditor confirm the likely_covered vs delta split + each rationale." + - "Have an ISO 27001 lead auditor confirm the likely_covered vs delta split + each rationale (-> validated)." - "Confirm each likely_covered item's relationship (supports vs partially_supports) and verification need." diff --git a/backend-compliance/reference_scenarios/generate.py b/backend-compliance/reference_scenarios/generate.py index 68e53270..4cb305fc 100644 --- a/backend-compliance/reference_scenarios/generate.py +++ b/backend-compliance/reference_scenarios/generate.py @@ -241,53 +241,43 @@ coverage_table([ ]) # ── Scenario 4 — Transition (RS-005 Planning Engine + Knowledge Pattern) ─── -w("## Szenario 4 — Transition ISO27001 → CRA (RS-005 + Pattern TP-ISO27001-CRA-v1)") +w("## Szenario 4 — Transition (RS-005 fährt JEDEN Knowledge Pattern)") w("") -w('_Frage: „Ich bin ISO27001-zertifiziert — was fehlt mir für den CRA?"_') +w("_Genericity-Beweis: derselbe Algorithmus trägt jeden Transition Knowledge Pattern, nicht nur den CRA._") w("") -_pat_path = os.path.join(os.path.dirname(__file__), "..", "knowledge", "transition_patterns", - "transition_pattern_iso27001_to_cra_v1.yaml") -with open(_pat_path, encoding="utf-8") as _f: - PAT = yaml.safe_load(_f) -# „habe": ISO27001 -> the pattern's likely_covered capabilities become INFERRED via Company 2A -_iso_caps = [a["capability"] for a in PAT["likely_covered"]] -_iso_map = {"ISO27001": CapabilityMappingEntry(capability_ids=_iso_caps, confidence=Confidence.MEDIUM)} -_profile = build_company_profile( - CompanyContext(company_id="iso-kunde", certifications=[Certification(certification_id="ISO27001")]), _iso_map) -# „required": likely_covered + delta -> TargetRequirements (here read from the pattern) -_reqs = [TargetRequirement(capability_id=a["capability"], question_intent="verify_existence", - expected_evidence=a.get("expected_evidence", [])) for a in PAT["likely_covered"]] -_reqs += [TargetRequirement(capability_id=d["capability"], question_intent=d.get("needed_information", "verify_existence"), - expected_evidence=d.get("expected_evidence", [])) for d in PAT["delta_requirements"]] -_tc = TransitionContext(company_id="iso-kunde", known_certifications=["ISO27001"], - target=TransitionGoal(target_id="CRA", target_type=TargetType.REGULATION, - label=PAT["transition_goal"]["to"]["regulation"])) -_a = assess_transition(_tc, _reqs, _profile) -w("**Input:** ISO27001-zertifiziert (Pattern TP-ISO27001-CRA-v1) → %d ISMS-Capabilities inferred; Ziel CRA." % len(_iso_caps)) -w("") -w("**Expected Transition Assessment (RS-005 v0 gegen den Pattern):**") -w("> Ziel %s · %s" % (_a.target_id, _a.summary.headline)) -w("") -w("**Delta zuerst (HIGH — fehlt einem ISO-27001-only-Hersteller):**") -for _r in _a.question_requests: - if _r.priority.value == "high": - w("- `%s` — intent=%s, Nachweis=%s" % (_r.capability_id, _r.question_intent, _r.expected_evidence)) -w("") -w("**Aus ISO27001 vermutlich abgedeckt (Produkt-Nachweis bestätigen):** %s" % ", ".join(_a.summary.probably_covered)) -w("") -_carried = len(_a.coverage) == len(_reqs) and len(_a.question_requests) > 0 -_n_high = sum(1 for _r in _a.question_requests if _r.priority.value == "high") -w("**Architektur-Test — trägt RS-005 den Pattern vollständig?** %d Pattern-Capabilities → %d Coverage + %d Question-Requests → **%s**." - % (len(_reqs), len(_a.coverage), len(_a.question_requests), "ja, vollständig getragen" if _carried else "NICHT vollständig")) -w("") -coverage_table([ - ("Pattern-Load (YAML)", "PASS", "TP-ISO27001-CRA-v1 (draft, gold-standard)"), - ("Company 2A (habe)", "PASS", "ISO27001 → %d inferred caps" % len(_a.summary.probably_covered)), - ("RS-005 Planning Engine", "PASS" if _carried else "PARTIAL", "Pattern → TransitionQuestionRequests"), - ("Transition ISO27001→CRA", "PASS" if _carried else "PARTIAL", - "%d Delta-Fragen (HIGH) + %d zu bestätigen" % (_n_high, len(_a.summary.probably_covered))), - ("RS-005.1 Renderer (Fragetext)", "TODO", "verschoben — Engine liefert nur Requests"), -]) +_pat_dir = os.path.join(os.path.dirname(__file__), "..", "knowledge", "transition_patterns") +_pat_files = sorted(f for f in os.listdir(_pat_dir) + if f.startswith("transition_pattern_") and f.endswith(".yaml")) +_t_rows: List[Row] = [] +for _pf in _pat_files: + with open(os.path.join(_pat_dir, _pf), encoding="utf-8") as _f: + PAT = yaml.safe_load(_f) + _src = "".join(c for c in PAT["transition_goal"]["from"]["standard"] if c.isalnum()) # e.g. ISOIEC27001 + _tgt = PAT["transition_goal"]["to"].get("regulation") or PAT["transition_goal"]["to"].get("framework") or "TARGET" + _have = [a["capability"] for a in PAT["likely_covered"]] + _map = {_src: CapabilityMappingEntry(capability_ids=_have, confidence=Confidence.MEDIUM)} + _profile = build_company_profile( + CompanyContext(company_id="kunde", certifications=[Certification(certification_id=_src)]), _map) + _reqs = [TargetRequirement(capability_id=a["capability"], question_intent="verify_existence", + expected_evidence=a.get("expected_evidence", [])) for a in PAT["likely_covered"]] + _reqs += [TargetRequirement(capability_id=d["capability"], question_intent=d.get("needed_information", "verify_existence"), + expected_evidence=d.get("expected_evidence", [])) for d in PAT["delta_requirements"]] + _tc = TransitionContext(company_id="kunde", known_certifications=[_src], + target=TransitionGoal(target_id=_tgt, target_type=TargetType.REGULATION, label=_tgt)) + _a = assess_transition(_tc, _reqs, _profile) + _carried = len(_a.coverage) == len(_reqs) and len(_a.question_requests) > 0 + _n_high = sum(1 for _r in _a.question_requests if _r.priority.value == "high") + w("**%s → %s** _(%s, status=%s)_" % (PAT["transition_goal"]["from"]["standard"], _tgt, PAT["id"], PAT["status"])) + w("> %s" % _a.summary.headline) + w("- Delta zuerst (HIGH): %s" % (", ".join(_r.capability_id for _r in _a.question_requests if _r.priority.value == "high") or "—")) + w("- vermutlich abgedeckt: %s" % (", ".join(_a.summary.probably_covered) or "—")) + w("- Pattern getragen: **%s** (%d caps → %d coverage + %d requests)" + % ("ja" if _carried else "NEIN", len(_reqs), len(_a.coverage), len(_a.question_requests))) + w("") + _t_rows.append(("Transition %s→%s" % (_src, _tgt), "PASS" if _carried else "PARTIAL", + "%s · %d HIGH-Delta + %d zu bestätigen" % (PAT["status"], _n_high, len(_a.summary.probably_covered)))) +_t_rows.append(("RS-005.1 Renderer (Fragetext)", "TODO", "verschoben — Engine liefert nur Requests")) +coverage_table(_t_rows) # ── Epics + roll-up ─────────────────────────────────────────────────────── w("## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert)") diff --git a/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md b/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md index 607dc560..95102c0a 100644 --- a/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md +++ b/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md @@ -145,38 +145,28 @@ _ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asse | Master Capability Registry | **PASS** | computed confidence, policy-versioniert | | cap ↔ MCAP Linking | **TODO** | zwei Vokabulare unverbunden → RS-003 | -## Szenario 4 — Transition ISO27001 → CRA (RS-005 + Pattern TP-ISO27001-CRA-v1) +## Szenario 4 — Transition (RS-005 fährt JEDEN Knowledge Pattern) -_Frage: „Ich bin ISO27001-zertifiziert — was fehlt mir für den CRA?"_ +_Genericity-Beweis: derselbe Algorithmus trägt jeden Transition Knowledge Pattern, nicht nur den CRA._ -**Input:** ISO27001-zertifiziert (Pattern TP-ISO27001-CRA-v1) → 8 ISMS-Capabilities inferred; Ziel CRA. +**ISO/IEC 27001 → TISAX** _(TP-ISMS-TISAX-v1, status=draft)_ +> 13 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 5 fehlt, 0 n/a, 0 nicht im Korpus. +- Delta zuerst (HIGH): data_protection_processing_on_behalf, prototype_protection, tisax_assessment_via_enx, tisax_label_scope_selection, vda_isa_self_assessment +- vermutlich abgedeckt: information_security_management, access_control_and_authentication, asset_and_configuration_management, incident_management, supplier_security, cryptography, physical_security, security_awareness_training +- Pattern getragen: **ja** (13 caps → 13 coverage + 13 requests) -**Expected Transition Assessment (RS-005 v0 gegen den Pattern):** -> Ziel CRA · 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus. - -**Delta zuerst (HIGH — fehlt einem ISO-27001-only-Hersteller):** -- `ce_conformity_assessment_and_technical_documentation` — intent=request_evidence, Nachweis=['technical_documentation', 'declaration_of_conformity'] -- `coordinated_vulnerability_disclosure` — intent=verify_existence, Nachweis=['cvd_policy'] -- `exploited_vuln_and_incident_reporting` — intent=verify_existence, Nachweis=['reporting_procedure'] -- `product_cyber_risk_assessment` — intent=verify_existence, Nachweis=['product_risk_assessment'] -- `public_security_advisories` — intent=verify_existence, Nachweis=['advisory_process'] -- `sbom_creation` — intent=determine_sbom_maturity, Nachweis=['sbom'] -- `secure_by_default_no_default_credentials` — intent=verify_existence, Nachweis=['config_export', 'test_report'] -- `secure_signed_update_distribution` — intent=verify_existence, Nachweis=['config_export', 'test_report'] -- `security_update_support_period` — intent=determine_duration, Nachweis=['support_policy', 'product_lifecycle_policy'] - -**Aus ISO27001 vermutlich abgedeckt (Produkt-Nachweis bestätigen):** incident_management, technical_vulnerability_management, supplier_security, access_control_and_authentication, cryptography, security_logging_and_monitoring, secure_development_lifecycle, asset_and_configuration_management - -**Architektur-Test — trägt RS-005 den Pattern vollständig?** 17 Pattern-Capabilities → 17 Coverage + 17 Question-Requests → **ja, vollständig getragen**. +**ISO/IEC 27001 → Cyber Resilience Act** _(TP-ISO27001-CRA-v1, status=reviewed)_ +> 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus. +- Delta zuerst (HIGH): ce_conformity_assessment_and_technical_documentation, coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting, product_cyber_risk_assessment, public_security_advisories, sbom_creation, secure_by_default_no_default_credentials, secure_signed_update_distribution, security_update_support_period +- vermutlich abgedeckt: incident_management, technical_vulnerability_management, supplier_security, access_control_and_authentication, cryptography, security_logging_and_monitoring, secure_development_lifecycle, asset_and_configuration_management +- Pattern getragen: **ja** (17 caps → 17 coverage + 17 requests) **Architecture Coverage** | Layer | Status | Hinweis | |---|---|---| -| Pattern-Load (YAML) | **PASS** | TP-ISO27001-CRA-v1 (draft, gold-standard) | -| Company 2A (habe) | **PASS** | ISO27001 → 8 inferred caps | -| RS-005 Planning Engine | **PASS** | Pattern → TransitionQuestionRequests | -| Transition ISO27001→CRA | **PASS** | 9 Delta-Fragen (HIGH) + 8 zu bestätigen | +| Transition ISOIEC27001→TISAX | **PASS** | draft · 5 HIGH-Delta + 8 zu bestätigen | +| Transition ISOIEC27001→Cyber Resilience Act | **PASS** | reviewed · 9 HIGH-Delta + 8 zu bestätigen | | RS-005.1 Renderer (Fragetext) | **TODO** | verschoben — Engine liefert nur Requests | ## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert) @@ -190,6 +180,6 @@ _Frage: „Ich bin ISO27001-zertifiziert — was fehlt mir für den CRA?"_ ## Suite-Status (Roll-up) -- Coverage-Zellen gesamt: **25** -- PASS: **17** · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 3 · N/A: 1 · NEEDS_FACTS: 0 +- Coverage-Zellen gesamt: **23** +- PASS: **15** · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 3 · N/A: 1 · NEEDS_FACTS: 0 - Fortschritt = PASS-Anteil steigt, wenn Epics RS-001…004 landen (objektiver Maßstab, kein LOC).