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 <noreply@anthropic.com>
This commit is contained in:
Benjamin Admin
@@ -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_<from>_to_<to>_v<n>.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`.
|
||||
|
||||
+191
@@ -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)."
|
||||
+43
-18
@@ -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."
|
||||
|
||||
Reference in New Issue
Block a user