# 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).

id: TP-ISO27001-CRA-v1
status: draft                 # draft -> reviewed -> approved (auditor review pending)
version: 1

transition_goal:
  from:
    standard: "ISO/IEC 27001"
    edition: "2022"
    nature: organizational_isms
  to:
    regulation: "Cyber Resilience Act"
    reference: "Regulation (EU) 2024/2847"
    applies_from: "2027-12-11"          # main obligations
    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"
  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_at: null

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").

# 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).
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
    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'."
    reviewable_claim: "A certified ISMS provides an incident-management foundation but does NOT by itself satisfy CRA product incident handling or Art. 14 reporting."

  - capability: technical_vulnerability_management
    iso27001_basis: [A.8.8]
    cra_target: [Annex_I_Part_II_2]
    relationship: supports
    verification: required
    expected_evidence: [vulnerability_management_procedure]
    rationale: "Internal vulnerability management exists; the CRA needs a PRODUCT-facing process (PSIRT, coordinated disclosure). Hence 'supports'."
    reviewable_claim: "Internal vulnerability management does NOT establish a product PSIRT or CVD."

  - capability: supplier_security
    iso27001_basis: [A.5.19, A.5.20, A.5.21, A.5.22]
    cra_target: [Annex_I_Part_II_1_components]
    relationship: supports
    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'."
    reviewable_claim: "Supplier security does NOT establish an SBOM or component vulnerability tracking."

  - capability: access_control_and_authentication
    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
    verification: required
    expected_evidence: [access_control_policy]
    rationale: "Org access control is mature; the CRA needs product authentication and no default credentials. Hence 'supports'."
    reviewable_claim: "Org access control does NOT guarantee product authentication or absence of default credentials."

  - capability: cryptography
    iso27001_basis: [A.8.24]
    cra_target: [Annex_I_Part_I_5, Annex_I_Part_I_6]
    relationship: partially_supports
    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'."
    reviewable_claim: "A crypto policy does NOT prove product-level confidentiality/integrity."

  - capability: security_logging_and_monitoring
    iso27001_basis: [A.8.15, A.8.16]
    cra_target: [Annex_I_Part_I_12]
    relationship: supports
    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'."
    reviewable_claim: "Org logging does NOT prove product security-event logging."

  - capability: secure_development_lifecycle
    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
    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'."
    reviewable_claim: "A secure-development policy does NOT prove CRA secure-by-design product properties."

  - capability: asset_and_configuration_management
    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
    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. ──
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
    expected_evidence: [sbom]
    priority: high
    reviewable_claim: "An ISO-27001-only manufacturer typically has no SBOM."

  - 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."
    needed_information: determine_duration
    expected_evidence: [support_policy, product_lifecycle_policy]
    priority: high
    reviewable_claim: "ISO 27001 does not define a product security-update support period."

  - 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."
    needed_information: verify_existence
    expected_evidence: [config_export, test_report]
    priority: high
    reviewable_claim: "ISO 27001 does not require signed product update distribution."

  - 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."
    needed_information: verify_existence
    expected_evidence: [cvd_policy]
    priority: high
    reviewable_claim: "ISO 27001 does not require a coordinated vulnerability disclosure policy."

  - 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."
    needed_information: verify_existence
    expected_evidence: [advisory_process]
    priority: medium
    reviewable_claim: "ISO 27001 does not require public product security advisories."

  - 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."
    needed_information: verify_existence
    expected_evidence: [reporting_procedure]
    priority: high
    reviewable_claim: "ISO 27001 does not establish CRA Art. 14 authority reporting."

  - 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."
    needed_information: verify_existence
    expected_evidence: [config_export, test_report]
    priority: medium
    reviewable_claim: "ISO 27001 does not guarantee secure-by-default product configuration."

  - 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."
    needed_information: verify_existence
    expected_evidence: [product_risk_assessment]
    priority: high
    reviewable_claim: "An organizational risk assessment is not a CRA product cyber risk assessment."

  - 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."
    needed_information: request_evidence
    expected_evidence: [technical_documentation, declaration_of_conformity]
    priority: high
    reviewable_claim: "An ISO 27001 certificate does not satisfy CRA conformity assessment."

# ── C) Explicit rejections — keep the certificate from being over-read. ──
rejected_assumptions:
  - "ISO 27001 does NOT establish a software bill of materials (SBOM)."
  - "ISO 27001 does NOT establish a PSIRT or a coordinated vulnerability disclosure process for the product."
  - "ISO 27001 does NOT define a product security-update support period."
  - "ISO 27001 does NOT produce CRA conformity assessment / CE marking / technical documentation."
  - "ISO 27001 does NOT cover Art. 14 reporting of exploited vulnerabilities to CSIRT/ENISA."
  - "ISO 27001 does NOT guarantee secure-by-default product configuration or absence of default credentials."

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.

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."
  - "Confirm each likely_covered item's relationship (supports vs partially_supports) and verification need."
