ISO 21434 lifecycle expansion: cybersecurity concept, validation evidence, continuous maintenance

[JohnASRG]

Motivation

methodology/ISO21434-Mapping.md is strong on Clause 15 (TARA) but thin on the lifecycle around it. Several Clause 9–12 work products still have no RDX home: cybersecurity concept (control allocation + rationale), cybersecurity validation/verification evidence (test cases, test results, coverage), and continuous risk maintenance (status over time, review cadence, validity, field feedback, incident/vulnerability linkage). This issue closes those gaps — orthogonal to #51 (cybersecurity requirements) and #61 (test coverage model), which it depends on.

Proposed change

1. cybersecurityConcept object on itemDefinition: controlAllocation[] (control → component(s) at a higher level than implementation), allocationRationale, concept-level securityClaimRefs.
2. continuousRiskMaintenance on riskValues[]: lastReviewedAt, nextReviewDueAt, reviewCadence (e.g., P3M), validityPeriod, fieldFeedbackRefs[], incidentRefs[], vulnerabilityRefs[], monitoringRefs[] (linking to Add monitoringAndDetection[] for MDR / detection engineering use cases #55 monitoringAndDetection[] entries).
3. reviewHistory[] at document level: reviewedAt, reviewerPartyRef, outcome, notes.
4. methodology/ISO21434-Mapping.md rewrite: expand to cover Clauses 5–12 with concrete RDX object mappings, not just TARA.

References

• AI peer review, section 7 ("ISO 21434 coverage is focused on TARA, but not the full lifecycle")
• Related: #51 (cybersecurity requirements), #59 (delta TARA), #55 (monitoring), upcoming P3 test-coverage issue

Acceptance criteria

• cybersecurityConcept, continuousRiskMaintenance, reviewHistory[] added in JSON Schema + XSD
• methodology/ISO21434-Mapping.md expanded to cover Clauses 5–12
• Example demonstrates a risk value with review cadence + field feedback linkage
• New RDX-XXX requirements added to REQUIREMENTS.md

---

Surfaced by external AI peer review; see chat transcript for full review text.