From bea8559f78bf7e339bac2c4e372bbb1bda37c889 Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Sat, 27 Jun 2026 07:50:42 +0200 Subject: [PATCH] docs(knowledge): first Transition Pattern ISO27001 -> CRA (curated knowledge base) Reasoning session's new Knowledge Acquisition responsibility (re-charter): build and curate the Transition Knowledge Base under backend-compliance/knowledge/transition_patterns/ (beside reasoning/, not under it -- it is knowledge, not an engine). First professional pattern TP-ISO27001-CRA-v1 (status: draft): separates what a mature ISMS likely covers at the ORG level (probably_covered, needs product-level confirmation, never auto-"erfuellt") from the CRA-specific delta with no ISO 27001 analogue (SBOM, support period + secure signed updates, coordinated vulnerability disclosure, Art. 14 authority reporting, product cyber risk assessment, CE conformity / technical documentation). Expert draft, not a normative proof; review_required before customer use. Non-runtime knowledge -> no deploy (ADR-001). Next: ISMS->TISAX. Co-Authored-By: Claude Opus 4.7 --- .../knowledge/transition_patterns/README.md | 44 +++++ ...transition_pattern_iso27001_to_cra_v1.yaml | 182 ++++++++++++++++++ 2 files changed, 226 insertions(+) create mode 100644 backend-compliance/knowledge/transition_patterns/README.md create mode 100644 backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml diff --git a/backend-compliance/knowledge/transition_patterns/README.md b/backend-compliance/knowledge/transition_patterns/README.md new file mode 100644 index 00000000..71f0fc5c --- /dev/null +++ b/backend-compliance/knowledge/transition_patterns/README.md @@ -0,0 +1,44 @@ +# Transition Patterns — 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). + +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). + +## 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). + +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). + +## File schema (per `transition_pattern__to__v.yaml`) + +`id` · `from_state` · `to_state` · `version` · `status` (draft → reviewed → approved) · +`provenance` (author/basis/reviewed_by/reviewed_at) · `disclaimer` · +`likely_covered_org_level[]` ({capability, source_basis, target_relevance, reuse_caveat, +confirm_question_intent, priority}) · `delta_requirements[]` ({capability, target_basis, why_delta, +question_intent, expected_evidence, priority}) · `ask_order_rationale` · `review_required[]`. + +## 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. +- **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. +- `capability` ids reference the (Execution-owned) Capability Registry MCAP ids once assigned. + +## Catalogue + +| Pattern | from → to | status | +|---|---|---| +| `transition_pattern_iso27001_to_cra_v1.yaml` | ISO 27001 → CRA | draft | + +Next candidates: `ISMS → TISAX`, `ISO 9001 → IATF 16949`, `ISO 14001 → CRA-Environmental`. 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 new file mode 100644 index 00000000..95494d0c --- /dev/null +++ b/backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml @@ -0,0 +1,182 @@ +# Transition Pattern — ISO/IEC 27001 (ISMS) -> CRA (Cyber Resilience Act, Reg. (EU) 2024/2847) +# Curated expert knowledge (NOT runtime code). Belongs to the Reasoning session's +# Knowledge Acquisition responsibility. Consumed later by the Transition Planning Engine +# (RS-005) and the Question Renderer (RS-005.1); rendered into a Transition Interview. + +id: TP-ISO27001-CRA-v1 +from_state: ISO27001 # ISO/IEC 27001:2022 (organizational ISMS) +to_state: CRA # Regulation (EU) 2024/2847 (product cybersecurity) +version: 1 +status: draft # draft -> reviewed -> approved (human/auditor review pending) +provenance: + author: "Claude (Reasoning session) — first expert draft" + basis: "ISO/IEC 27001:2022 Annex A controls vs CRA Annex I (Part I security requirements, + Part II vulnerability handling) + reporting (Art. 14) + support period (Art. 13) + + conformity assessment / CE / technical documentation (Annex VII)." + reviewed_by: null + reviewed_at: null + +disclaimer: > + Expert DRAFT, not a normative or legal proof that these points exactly represent either + standard. KEY ASYMMETRY: ISO 27001 is ORGANIZATIONAL (an ISMS); the CRA is PRODUCT-level + (security of products with digital elements). Therefore an existing ISO 27001 capability + is at most a Welt-1 hint ("probably covered, organizationally") and ALWAYS needs PRODUCT- + level evidence before it counts for the CRA — it is never automatically "erfüllt". + +# ────────────────────────────────────────────────────────────────────────── +# A) LIKELY COVERED at the organizational level by a mature ISMS. +# -> status "probably_covered"; each still needs a PRODUCT-level confirmation question. +# ────────────────────────────────────────────────────────────────────────── +likely_covered_org_level: + - capability: incident_management + iso27001_basis: [A.5.24, A.5.25, A.5.26, A.5.27, A.5.28] + cra_relevance: [Annex_I_Part_II_handling, Art_14_reporting] + reuse_caveat: "An incident process exists organizationally. The CRA delta is PRODUCT incident + handling AND mandatory reporting of actively exploited vulnerabilities / severe incidents to + the CSIRT/ENISA (Art. 14) — that authority-reporting duty has no ISO 27001 analogue." + confirm_question_intent: verify_product_scope + priority: medium + + - capability: technical_vulnerability_management + iso27001_basis: [A.8.8] + cra_relevance: [Annex_I_Part_II_2] + reuse_caveat: "Internal vulnerability management is likely in place. The CRA delta is a PRODUCT- + facing process: PSIRT + coordinated vulnerability disclosure + advisories (below)." + confirm_question_intent: verify_product_scope + priority: medium + + - capability: supplier_security + iso27001_basis: [A.5.19, A.5.20, A.5.21, A.5.22] + cra_relevance: [Annex_I_Part_II_1_components] + reuse_caveat: "Supplier security exists; the CRA delta is component-level transparency (SBOM) + and tracking vulnerabilities in third-party / open-source components." + confirm_question_intent: verify_product_scope + priority: medium + + - capability: access_control_and_authentication + iso27001_basis: [A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.5] + cra_relevance: [Annex_I_Part_I_4] + reuse_caveat: "Org access control is mature; the CRA delta is product authentication, no default + credentials, and protection of the product against unauthorized access." + confirm_question_intent: verify_existence + priority: medium + + - capability: cryptography + iso27001_basis: [A.8.24] + cra_relevance: [Annex_I_Part_I_5, Annex_I_Part_I_6] + reuse_caveat: "Crypto policy exists; the CRA delta is product-level confidentiality (encryption) + and integrity of data, commands, configuration and code." + confirm_question_intent: verify_existence + priority: low + + - capability: security_logging_and_monitoring + iso27001_basis: [A.8.15, A.8.16] + cra_relevance: [Annex_I_Part_I_12] + reuse_caveat: "Logging/monitoring exists organizationally; the CRA delta is recording security- + relevant events ON the product (with an opt-out)." + confirm_question_intent: verify_existence + priority: low + + - capability: secure_development_lifecycle + iso27001_basis: [A.8.25, A.8.27, A.8.28, A.8.29] + cra_relevance: [Annex_I_Part_I_1, Annex_I_Part_II_3] + reuse_caveat: "Secure development exists; the CRA delta is demonstrating secure-by-design product + properties and regular security tests/reviews of the product." + confirm_question_intent: verify_existence + priority: medium + + - capability: asset_and_configuration_management + iso27001_basis: [A.5.9, A.5.10, A.5.11, A.8.9] + cra_relevance: [Annex_I_Part_II_1_SBOM] + reuse_caveat: "Asset/config management underpins an SBOM but is NOT an SBOM. The SBOM itself is a + delta item (below)." + confirm_question_intent: verify_existence + priority: low + +# ────────────────────────────────────────────────────────────────────────── +# B) DELTA — CRA-specific requirements with NO ISO 27001 analogue. +# -> status "missing" for an ISO-27001-only company; ask these FIRST. +# ────────────────────────────────────────────────────────────────────────── +delta_requirements: + - capability: sbom_creation + cra_basis: "Annex I, Part II (1) — identify and document components, incl. a software bill of materials." + why_delta: "ISO 27001 has no SBOM requirement." + question_intent: determine_sbom_maturity # enum: never / manual / automatic / continuous + expected_evidence: [sbom] + priority: high + + - capability: security_update_support_period + cra_basis: "Art. 13(8) support period (default >= 5 years) + Annex I Part I (3) / Part II (2,7) — provide security updates." + why_delta: "ISO 27001 defines no product support period or update-provision duty." + question_intent: determine_duration + expected_evidence: [support_policy, product_lifecycle_policy] + priority: high + + - capability: secure_signed_update_distribution + cra_basis: "Annex I, Part II (8) — ensure security updates are disseminated securely (authenticity/integrity)." + why_delta: "ISO integrity controls exist, but signed product update distribution is product-specific." + question_intent: verify_existence + expected_evidence: [config_export, test_report] + priority: high + + - capability: coordinated_vulnerability_disclosure + cra_basis: "Annex I, Part II (5,6) — CVD policy + a contact address for reporting vulnerabilities." + why_delta: "ISO vulnerability management is internal; a product-facing CVD policy / PSIRT is the delta." + question_intent: verify_existence + expected_evidence: [policy] + priority: high + + - capability: public_security_advisories + cra_basis: "Annex I, Part II (4,7) — publicly disclose information about fixed vulnerabilities; provide advisories." + why_delta: "No ISO 27001 obligation to publish product security advisories." + question_intent: verify_existence + expected_evidence: [policy] + priority: medium + + - capability: exploited_vuln_and_incident_reporting + cra_basis: "Art. 14 — report actively exploited vulnerabilities and severe incidents to CSIRT/ENISA (24h early warning, 72h notification, final report)." + why_delta: "No ISO 27001 analogue; this is a statutory authority-reporting duty with fixed deadlines." + question_intent: verify_existence + expected_evidence: [policy, ticket] + priority: high + + - capability: secure_by_default_no_default_credentials + cra_basis: "Annex I, Part I (2,4) — secure default configuration; no default passwords / forced change." + why_delta: "A product property, not an ISMS control." + question_intent: verify_existence + expected_evidence: [config_export, test_report] + priority: medium + + - capability: attack_surface_minimization + cra_basis: "Annex I, Part I (10,11) — limit attack surfaces; mitigate exploitation." + why_delta: "Product hardening property; not an ISO 27001 control." + question_intent: verify_existence + expected_evidence: [test_report, pentest] + priority: medium + + - capability: product_cyber_risk_assessment + cra_basis: "Annex I + technical documentation — cybersecurity risk assessment of the PRODUCT." + why_delta: "ISO 27001 risk assessment is organizational; the CRA needs a product cyber risk assessment." + question_intent: verify_existence + expected_evidence: [test_report, audit_log] + priority: high + + - capability: ce_conformity_assessment_and_technical_documentation + cra_basis: "Conformity assessment + CE marking + EU Declaration of Conformity + technical documentation (Annex VII)." + why_delta: "An ISO 27001 certificate is NOT a CRA conformity assessment; the product-compliance dossier is the delta." + question_intent: request_evidence + expected_evidence: [test_report, audit_log] + priority: high + +# Suggested ask-order for an ISO-27001-only manufacturer moving to the CRA: +ask_order_rationale: > + Ask the delta first — SBOM, support period + secure updates, coordinated vulnerability disclosure, + authority reporting (Art. 14), product cyber risk assessment, and CE conformity / technical + documentation. These have no ISO 27001 analogue and are where the real CRA work sits. The + org-level capabilities above reduce effort but must each be re-scoped and re-evidenced at the + PRODUCT level — never assumed "erfüllt" from the certificate alone. + +review_required: + - "Validate CRA Annex/Article references with counsel before customer use (indicative here)." + - "Confirm the MCAP capability ids once the Capability Registry assigns them (placeholders here)." + - "Have an ISO 27001 lead auditor sanity-check the likely_covered vs delta split."