Monitoring & Incident Management

Under UNECE R155, manufacturers must actively monitor, detect, analyze, and respond to cybersecurity threats and vulnerabilities affecting vehicles in the field, and must continuously improve their posture. This page outlines typical expectations for monitoring, vulnerability handling (PSIRT), incident response, and feedback into the CSMS.

Objectives

Continuously monitor security-relevant signals from vehicles, backends, and suppliers.
Operate a vulnerability intake and triage process (internal, supplier, public).
Run a PSIRT (Product Security Incident Response Team) to handle incidents end-to-end.
Coordinate corrective actions (incl. software updates per R156/ISO 24089).
Feed lessons learned back into the CSMS, TARA, requirements, testing, and training.

Monitoring (Detection & Telemetry)

Data sources: on-board logs/IDS, update client, diagnostics, backend security tools, supplier advisories, threat intelligence.
KPI/thresholds: define alert thresholds, severity criteria, and escalation paths.
Signal quality: time sync, integrity, anti-tamper on telemetry and logs.
Privacy & compliance: data minimization, purpose limitation, retention policies, and lawful basis for processing operational data.
Coverage: critical ECUs, external interfaces (telecom, Wi-Fi/BLE, OBD, V2X), and backend entry points impacting the vehicle.

Vulnerability Intake & Triage

Intake channels: responsible disclosure page, security mailbox, bug bounty, supplier portals, internal testing findings.
Triage: de-duplicate, reproduce, assign preliminary severity (impact × feasibility), and link to affected types/variants.
Tracking: unified ticketing with SLAs; link to residual risk register and TARA items.
Supplier coordination: share details under NDA; align fix ownership and timelines.
CVE/CVSS: map where applicable and record scores/rationale.

PSIRT & Incident Response Lifecycle

Detect & declare – confirm incident criteria; assign incident commander.
Assess & contain – scope, affected VINs/variants, temporary mitigations.
Eradicate & recover – corrective updates/config changes; coordinate with SUMS (R156).
Communicate – authorities, customers, dealers; clear instructions and timelines.
Post-incident review – root cause, control effectiveness, lessons learned, CAPA actions.

Severity, SLAs & Escalation

Severity classes: e.g., Sev-1 (safety/regulatory), Sev-2 (operational), Sev-3 (limited exposure). Define clear thresholds.
SLAs: acknowledgment, triage, containment, corrective action availability, and rollout windows appropriate to severity and risk.
Escalation: CSMS board for risk acceptance/waivers; legal/regulatory for notifications.

Coordinated Vulnerability Disclosure (CVD)

Publicly documented policy with scope, expected timelines, and safe-harbor language.
Secure channel for submissions and optional encryption key.
Researcher acknowledgment, tracking ID, and status updates.
Credit/attribution where appropriate and coordinated release notes.

Alignment with R156 / ISO 24089

Corrective actions frequently involve software updates. Ensure package signing, chain of trust, anti-rollback, eligibility checks, staged rollout , and post-update validation are in place and traceable to the incident ticket and risk assessment.

Feedback into CSMS & TARA

Update TARA scenarios, feasibility factors, and controls based on incident data.
Revise requirements, test depth (e.g., fuzzing), and supplier criteria.
Train teams and refine monitoring KPIs to improve detection time and containment.

Practical Do / Don’t

Do

Maintain a single PSIRT playbook with roles, checklists, and contacts.
Instrument systems for actionable telemetry and integrity-protected logs.
Rehearse incidents (table-tops/red-team) and measure MTTA/MTTR.
Link every corrective update to a tracked incident and risk record.
Share advisories with suppliers and dealers using a controlled portal.

Don’t

Collect excessive personal data without purpose/retention controls.
Ship updates without provenance, signature verification, or rollback strategy.
Close incidents without post-mortem and control effectiveness review.
Depend on email alone for researcher intake; provide a web form and PGP key.

Typical Outputs / Evidence

Monitoring plan, KPIs/thresholds, and dashboards/screenshots (with dates/versions).
Vulnerability intake policy and tickets with time-stamped SLA records.
PSIRT playbook, RACI, contact lists, and incident runbooks.
Incident records: timelines, root cause analyses, corrective actions, communications.
Links to R156/SUMS artifacts: signed packages, eligibility rules, rollout reports, post-update validation.
Lessons-learned reports and CSMS improvement actions; updated TARA artifacts.

Disclaimer: This page summarizes monitoring and incident management expectations under UNECE R155. For authoritative requirements, consult the regulation text and your approval authority’s guidance.