Introduction: Cybersecurity for the Software-Defined Vehicle
The modern vehicle is a distributed computer on wheels. A premium car today ships with 100 or more Electronic Control Units (ECUs), well over 100 million lines of code, multiple in-vehicle networks (CAN, CAN-FD, LIN, FlexRay, Automotive Ethernet), wireless interfaces (Bluetooth, Wi-Fi, cellular telematics, UWB digital key), and cloud back-ends that deliver over-the-air (OTA) updates and connected services. Every one of these interfaces is an attack surface, and a successful compromise is not merely a data-privacy event: it can influence steering, braking, acceleration and airbag deployment, placing human life directly at risk. This is why automotive cybersecurity has become a mandatory, type-approval-gating discipline rather than an optional good practice.
Two instruments dominate this landscape and are almost always implemented together. ISO/SAE 21434:2021 'Road vehicles — Cybersecurity engineering' is the engineering standard that defines HOW to build cybersecurity into a vehicle across its full lifecycle. UNECE Regulation No. 155 (UN R155) is the LEGAL regulation, adopted under the 1958 Agreement, that makes a certified Cyber Security Management System (CSMS) a precondition for vehicle type approval in the 60-plus contracting parties to the UNECE World Forum (WP.29), including the EU, UK, Japan and Korea. R155 tells you WHAT the regulator demands; ISO 21434 gives you the recognised method to demonstrate it. A twin regulation, UN R156, applies the same philosophy to Software Update Management Systems (SUMS). This guide treats ISO 21434 and R155 as a single, integrated scheme, because in practice an OEM cannot achieve one without the other.
This deep-dive is written for two audiences at once. For the auditor or assessor — whether a Technical Service performing R155 conformity assessment, an internal audit function, or a Tier-1 supplier's second-party assessor — it enumerates every clause, work product and control area with the specific evidence to demand. For the implementer — the product cybersecurity engineer, the CISO of an automotive OEM or supplier, the TARA analyst, the SUMS owner — it lays out a phased implementation programme, a capability model, and a readiness checklist. CyberSigma delivers both sides: gap assessment and audit readiness on one hand, and hands-on CSMS build-out, TARA facilitation and evidence engineering on the other.
What is ISO/SAE 21434 and UNECE R155?
ISO/SAE 21434:2021 is a process-oriented, risk-based engineering standard. It does not prescribe specific technical controls (it will not tell you to use AES-256 or a particular secure boot scheme). Instead it defines a framework of activities, roles, and 'work products' (documented outputs) that an organisation must produce across the entire lifecycle of a road-vehicle Electrical/Electronic (E/E) system — from concept, through development, production, operations and maintenance, to decommissioning. Its central engineering method is Threat Analysis and Risk Assessment (TARA), and its central organisational construct is the Cybersecurity Management System, spanning both the organisation as a whole and each individual project.
The standard is structured around a set of numbered clauses (Clauses 5 to 15) supported by annexes. It borrows heavily in spirit from ISO 26262 (functional safety) — same lifecycle, same rigour, same emphasis on independence and traceability — but reorients the analysis from random hardware faults to intentional, intelligent adversaries. A key conceptual output of ISO 21434 is a Cybersecurity Assurance Level (CAL) and a set of risk-treatment decisions, plus the Cybersecurity Case and the Cybersecurity Assessment report.
UNECE R155 sits above ISO 21434 as binding law in adopting markets. It requires two things of a vehicle manufacturer. First, a Certificate of Compliance for a Cyber Security Management System (CSMS) — an organisation-level certificate, valid for a maximum of three years, granted by an Approval Authority (or its Technical Service) after auditing that the manufacturer has processes to manage cyber risk across development, production and post-production, including monitoring, incident response and reporting. Second, a vehicle type approval, granted per vehicle type only if the manufacturer holds a valid CSMS certificate and can demonstrate that the specific type's risks have been assessed and treated. R155 Annex 5 provides a catalogue of threats, vulnerabilities and mitigations that the type-level risk assessment must address. ISO 21434 is the de facto method by which manufacturers satisfy R155; the two are complementary, not alternative.
Who must comply?
R155 places the legal obligation squarely on the vehicle manufacturer (OEM), but ISO 21434 explicitly extends responsibility along the entire distributed development and supply chain through its 'Distributed Cybersecurity Activities' clause and the Cybersecurity Interface Agreement (CIA). In practice, anyone contributing to a vehicle's E/E systems is drawn into scope.
| Party | Obligation and typical role |
|---|---|
| Vehicle manufacturer (OEM) | Legally accountable under R155. Holds the CSMS and SUMS certificates and each vehicle type approval. Owns overall risk, defines cybersecurity goals, integrates supplier evidence, and reports incidents to the Approval Authority. |
| Tier-1 supplier | Delivers ECUs, domain controllers, gateways or software stacks. Must operate an ISO 21434-conformant process, produce component-level TARAs and work products, and sign Cybersecurity Interface Agreements allocating responsibilities with the OEM. |
| Tier-2 / Tier-n suppliers | Provide chips (SoCs, HSMs, MCUs), RTOS, hypervisors, communication stacks, cryptographic libraries. Must supply cybersecurity assurance information and support the supply-chain TARA; silicon vendors increasingly provide their own security certifications. |
| Software / OTA and cloud service providers | Telematics platforms, OTA campaign managers, connected-service back-ends. Fall under both ISO 21434 and R156/SUMS; back-end security is explicitly in R155 scope. |
| Aftermarket and connected-service vendors | Diagnostic tools, charging infrastructure, fleet-management, insurance dongles interfacing with the vehicle. May be pulled into the OEM's risk assessment as attack vectors. |
| Approval Authorities and Technical Services | Not 'compliant' parties but the assessors: they audit the CSMS, witness/review the type-level risk assessment, and issue certificates and approvals. |
| Type-approval-market importers | Manufacturers exporting into EU, UK, Japan, Korea and other WP.29 markets must comply regardless of where the vehicle is designed or built. |
Geographic reach: R155 binds the 1958 Agreement contracting parties. Markets that follow WP.29 (EU-27, UK, Japan, South Korea, and many others) enforce it directly for type approval. Markets outside WP.29 (notably the USA under NHTSA/FMVSS, and China under its own GB/T and MIIT regime) do not mandate R155 by law, but global OEMs almost universally adopt ISO 21434 as the single engineering baseline for all markets to avoid maintaining divergent processes.
Structure of ISO/SAE 21434 (clauses and work products)
The normative content of ISO 21434 lives in Clauses 5 through 15, each defining objectives, requirements (identified as RQ-nn-xx), recommendations (RC), permissions (PM), and prescribed work products (WP-nn-xx). The table below maps the clause structure and how it flows across the lifecycle.
| Clause / domain | Focus and key work products |
|---|---|
| Clause 5 — Organisational cybersecurity management | Cybersecurity governance, policy, rules and processes; competence management; a cybersecurity culture; tool management; information sharing; the organisational cybersecurity audit. Establishes the org-level CSMS. WP: cybersecurity policy, rules & processes, evidence of competence. |
| Clause 6 — Project-dependent cybersecurity management | Cybersecurity responsibilities and planning at the project level; tailoring; reuse; component out-of-context and off-the-shelf handling; the Cybersecurity Case; the Cybersecurity Assessment; release for post-development. WP: cybersecurity plan, cybersecurity case, assessment report. |
| Clause 7 — Distributed cybersecurity activities | Supplier capability evaluation; the Request for Quotation cybersecurity requirements; the Cybersecurity Interface Agreement (RASIC of responsibilities between customer and supplier). WP: CIA, supplier evaluation records. |
| Clause 8 — Continual cybersecurity activities | Cybersecurity monitoring; cybersecurity event evaluation; vulnerability analysis; vulnerability management. Runs continuously across the whole lifecycle. WP: sources of information, triage records, vulnerability analysis. |
| Clause 9 — Concept phase | Item definition; cybersecurity goals; cybersecurity claims; and the concept-level TARA. Defines what is being protected and why. WP: item definition, cybersecurity goals, cybersecurity concept. |
| Clause 10 — Product development | Refinement of cybersecurity requirements to hardware/software; design; secure implementation; integration and verification. WP: cybersecurity specifications, verification reports. |
| Clause 11 — Cybersecurity validation | Validation at the vehicle level that cybersecurity goals are met and residual risk is acceptable. WP: validation report. |
| Clause 12 — Production | Cybersecurity in manufacturing: key injection, provisioning, protection of production data and secrets, control plan. WP: production control plan. |
| Clause 13 — Operations and maintenance | Cybersecurity incident response; updates in the field. WP: incident response plan. |
| Clause 14 — End of cybersecurity support and decommissioning | Managing end-of-support communication and secure decommissioning. WP: decommissioning provisions. |
| Clause 15 — Threat analysis and risk assessment (TARA) methods | The core analytical method: asset identification, threat scenario identification, impact rating, attack path analysis, attack feasibility rating, risk value determination, risk treatment decision. Referenced by Clauses 9-11. WP: TARA work products. |
| Annexes A-H / R155 Annex 5 | Guidance, examples, CAL determination, and the R155 threat/mitigation catalogue used for the type-level risk assessment. |
Two cross-cutting scoring constructs sit inside this structure. The Cybersecurity Assurance Level (CAL 1 to CAL 4) expresses the rigour with which activities must be performed, derived from impact and attack feasibility. The risk value (1 to 5) is the output of the TARA per threat scenario and drives the risk-treatment decision (reduce, share/transfer, retain, or avoid).
Master assessment checklist — clause-by-clause
This is the operational heart of the guide. Every ISO 21434 clause and every R155 obligation is enumerated below as an assessment group, each with a table of 'What to verify' against 'Typical evidence'. Auditors should treat each row as a test step; implementers should treat each row as a control to build and an artefact to produce. No clause is skipped.
5. Organisational cybersecurity management (org-level CSMS)
| What to verify | Typical evidence |
|---|---|
| A cybersecurity policy and governance mandate exist, endorsed by executive management, with clear accountability (e.g. a designated cybersecurity manager / CISO). | Signed cybersecurity policy; RACI; org chart; management review minutes. |
| Organisation-wide rules and processes for cybersecurity engineering are defined, documented and deployed across projects. | Process manuals, procedure documents, quality-management-system integration records. |
| A cybersecurity culture is fostered — awareness, disciplined engineering, and support for reporting concerns. | Awareness campaign records, code-of-practice, whistle-blower/reporting mechanism. |
| Competence management ensures personnel performing cybersecurity activities are trained and qualified. | Competence matrix, training records, certification of engineers and assessors. |
| Tools used for cybersecurity activities are managed so as not to introduce or mask errors. | Tool qualification / tool confidence records, tool inventory. |
| An organisational cybersecurity audit is planned and performed independently of the activities audited. | Internal audit plan, audit reports, corrective-action tracking, evidence of assessor independence. |
| Information sharing arrangements (internal and external, e.g. Auto-ISAC) are established. | Membership records, information-sharing procedure, threat-intel feeds. |
6. Project-dependent cybersecurity management
| What to verify | Typical evidence |
|---|---|
| Cybersecurity responsibilities are assigned at the project level and a cybersecurity plan exists covering all lifecycle activities. | Project cybersecurity plan, responsibility assignment, milestone schedule. |
| Tailoring of activities is justified and documented (activities added, omitted or reordered with rationale). | Tailoring record with justification approved by the cybersecurity manager. |
| Reuse of existing components and out-of-context / off-the-shelf items is assessed for cybersecurity impact. | Reuse analysis, component-out-of-context assumptions, OTS evaluation records. |
| A Cybersecurity Case is compiled that argues, with evidence, that residual risk is acceptable. | Cybersecurity case document referencing all supporting work products. |
| A Cybersecurity Assessment (independent) judges the achieved cybersecurity of the item/component. | Assessment plan, assessment report, independence declaration, recommendation for acceptance. |
| Release for post-development is authorised only after the case and assessment are complete. | Release-for-production record with sign-off authority. |
7. Distributed cybersecurity activities (supply chain)
| What to verify | Typical evidence |
|---|---|
| Supplier cybersecurity capability is evaluated before award. | Supplier capability assessment questionnaire and score, audit reports, maturity ratings. |
| Cybersecurity requirements are included in the Request for Quotation. | RFQ cybersecurity requirement annex, statement of work. |
| A Cybersecurity Interface Agreement (CIA) allocates every responsibility between customer and supplier (RASIC). | Signed CIA with responsibility matrix, joint cybersecurity plan, escalation paths. |
| Shared work products, milestones and interfaces are defined and tracked. | Interface work-product list, review records, joint TARA alignment. |
8. Continual cybersecurity activities (monitoring & vulnerability management)
| What to verify | Typical evidence |
|---|---|
| Cybersecurity monitoring collects information from defined internal and external sources (CVE feeds, researchers, field, Auto-ISAC). | List of sources, monitoring procedure, intake logs, PSIRT charter. |
| Cybersecurity events are triaged and evaluated for relevance to the organisation's items and components. | Event evaluation records, triage criteria, disposition decisions. |
| Vulnerabilities are analysed for exploitability and impact, with attack-feasibility reasoning. | Vulnerability analysis records, CVSS/attack-feasibility scoring, affected-asset mapping. |
| Vulnerabilities are managed to closure — remediation, mitigation, or accepted residual risk with rationale. | Vulnerability register, remediation tickets, OTA campaign records, risk-acceptance sign-offs. |
9. Concept phase (item definition, goals, concept TARA)
| What to verify | Typical evidence |
|---|---|
| The item is defined: boundary, functions, interfaces, operational environment and preliminary architecture. | Item definition document, boundary diagram, interface list. |
| A concept-level TARA identifies assets, damage scenarios, threat scenarios, impact and attack-feasibility ratings, and risk values. | Concept TARA report per Clause 15 method. |
| Cybersecurity goals are derived from unacceptable risks and expressed as top-level requirements. | Cybersecurity goals list traced to threat scenarios. |
| Cybersecurity claims / assumptions on the operational environment are stated. | Cybersecurity claims register, environmental assumptions. |
| A cybersecurity concept allocates goals to controls/requirements and derives CALs. | Cybersecurity concept document, CAL determination records. |
10. Product development (design, implementation, integration & verification)
| What to verify | Typical evidence |
|---|---|
| Cybersecurity requirements are refined and allocated to hardware and software components with traceability. | Requirement specification, traceability matrix (goal to requirement to design). |
| The design applies recognised principles: defence-in-depth, least privilege, secure boot, secure storage of keys (HSM), authenticated communication, hardening. | Architecture/design documents, security design review records, threat-model updates. |
| Secure implementation follows coding standards (e.g. MISRA, CERT C) and avoids known weakness classes (CWE). | Coding guidelines, static analysis (SAST) reports, code-review records. |
| Integration and verification test cybersecurity requirements: functional security tests, vulnerability scanning, fuzz testing, penetration testing. | Test plans, SAST/DAST/SCA results, fuzzing reports, penetration-test reports, requirement-based test coverage. |
| Weaknesses found during verification are analysed and resolved. | Defect register, closure evidence, regression results. |
11. Cybersecurity validation
| What to verify | Typical evidence |
|---|---|
| Vehicle-level validation confirms cybersecurity goals are met and the cybersecurity concept is adequate. | Validation plan and report at vehicle/system level. |
| Residual risk after validation is judged acceptable against defined criteria. | Residual-risk statement, acceptance sign-off. |
| Validation includes adversarial testing representative of real attack paths. | Vehicle-level penetration test / red-team report. |
12. Production
| What to verify | Typical evidence |
|---|---|
| A production cybersecurity control plan protects the manufacturing process (key/secret injection, provisioning, personalisation). | Production control plan, key-management procedure, HSM provisioning records. |
| Cybersecurity requirements applicable to production (e.g. no debug ports enabled, immutable configuration) are enforced. | End-of-line test specs, configuration lockdown evidence. |
| Production data and secrets are protected against theft or manipulation. | Access-control records for production systems, secret-handling audit. |
13. Operations and maintenance (incident response & field updates)
| What to verify | Typical evidence |
|---|---|
| A cybersecurity incident response plan exists, is tested, and defines detection, analysis, containment, remediation and communication. | IR plan/playbooks, tabletop-exercise records, PSIRT process. |
| Field remediation via updates (OTA) is governed under the SUMS / R156, with integrity and authenticity protection. | OTA campaign records, update integrity design, SUMS certificate. |
| Regulatory and customer reporting of incidents is performed within required timelines. | Incident reporting log to Approval Authority, notification templates. |
14. End of cybersecurity support and decommissioning
| What to verify | Typical evidence |
|---|---|
| End of cybersecurity support is planned and communicated to affected parties and customers. | End-of-support policy, customer communication records, dates published. |
| Decommissioning provisions ensure secure disposal (secrets erased, credentials revoked, back-end access removed). | Decommissioning procedure, key-revocation records. |
15. TARA method — the analytical core
| What to verify | Typical evidence |
|---|---|
| Asset identification lists cybersecurity properties (confidentiality, integrity, availability, authenticity) to be protected. | Asset register with property mapping. |
| Threat scenarios are identified (e.g. via STRIDE, attack trees) against each asset. | Threat catalogue, STRIDE mapping, attack trees. |
| Impact ratings are assigned across categories: Safety, Financial, Operational, Privacy (S/F/O/P). | Impact-rating table with justification per damage scenario. |
| Attack path analysis and attack feasibility are rated (e.g. using CVSS-based or attack-potential/vector approach). | Attack-path diagrams, feasibility scoring worksheets. |
| Risk value (1-5) is determined by combining impact and feasibility. | Risk matrix, computed risk values per threat scenario. |
| A risk-treatment decision (avoid, reduce, share/transfer, retain) is made and justified for each risk. | Risk-treatment register with owner and rationale. |
R155 / R156 regulatory obligations (over and above ISO 21434)
| What to verify | Typical evidence |
|---|---|
| A certified CSMS covers development, production and post-production phases and is valid (max 3 years). | CSMS Certificate of Compliance and its scope statement. |
| The type-level risk assessment addresses the R155 Annex 5 threat and mitigation catalogue. | Annex-5 coverage matrix mapping each listed threat to a mitigation and evidence. |
| The manufacturer monitors, detects and responds to attacks and reports to the Approval Authority. | Monitoring/detection capability evidence, reporting procedure, incident logs. |
| A SUMS is certified under R156 and each software update has a unique RxSWIN and integrity protection. | SUMS certificate, RxSWIN management records, update integrity design. |
| Post-production cybersecurity is maintained for the vehicle's operational life. | Field-monitoring evidence, update roadmap, support-period declaration. |
Scoping the assessment
Correct scoping determines both the effort and the credibility of the outcome. ISO 21434 scope is defined by the 'item' and its 'components', and by the phases of the lifecycle in play. R155 scope is defined by the organisation (for the CSMS) and by the vehicle type (for the approval).
- Item boundary: define exactly which E/E systems and functions are in scope — typically connected/safety-relevant domains first (telematics/T-box, infotainment/IVI, central gateway, ADAS/AD domain controller, body/comfort domains, battery-management and powertrain for EVs).
- Interfaces and attack surface: enumerate every external interface — cellular, Wi-Fi, Bluetooth, USB, OBD-II diagnostic port, charging (for EVs, ISO 15118), keyless entry (UWB/BLE/RF), OTA back-end, and any V2X.
- Lifecycle phases in scope: concept only, full development, or including production and operations — a supplier delivering a component may exclude vehicle-level validation but must cover its CIA obligations.
- Organisational vs project scope: the CSMS audit is organisation-wide; each TARA and cybersecurity case is per item/type. Clarify which is being assessed.
- Supply-chain depth: decide how far down the Tier-n chain the assessment reaches, and which responsibilities are covered by Cybersecurity Interface Agreements.
- Exclusions and assumptions: document out-of-scope elements (e.g. legacy carry-over parts, aftermarket devices) and the environmental cybersecurity claims relied upon.
- Markets: identify which type-approval markets (EU, UK, Japan, Korea) apply, since this fixes whether R155/R156 certification is mandatory.
Implementation approach (phased programme)
CyberSigma delivers ISO 21434 / R155 readiness as a structured, phased programme. Each phase has defined activities and deliverables and maps to the standard's lifecycle.
Phase 1 — Govern: establish the CSMS (Clause 5)
Activities: appoint a cybersecurity manager; draft cybersecurity policy, rules and processes; build the competence matrix and training plan; define tool management and information-sharing (Auto-ISAC); integrate cybersecurity into the existing IATF 16949 / ASPICE / ISO 26262 quality system; plan the organisational cybersecurity audit.
Deliverables: cybersecurity policy; process framework; RACI and competence matrix; CSMS scope statement ready for certification audit.
Phase 2 — Plan: project cybersecurity management (Clauses 6 & 7)
Activities: for each project, create the cybersecurity plan; assign responsibilities; perform tailoring with justification; evaluate suppliers and execute Cybersecurity Interface Agreements; set up the traceability toolchain.
Deliverables: project cybersecurity plan; tailoring record; supplier evaluations; signed CIAs; interface work-product list.
Phase 3 — Analyse: concept and TARA (Clauses 9 & 15)
Activities: produce the item definition; facilitate the TARA workshop (asset identification, damage/threat scenarios, S/F/O/P impact rating, attack-path and feasibility analysis, risk determination and treatment); derive cybersecurity goals and CALs; map to R155 Annex 5.
Deliverables: item definition; TARA report; cybersecurity goals; cybersecurity concept; CAL determination; Annex-5 coverage matrix.
Phase 4 — Build: secure product development (Clause 10)
Activities: refine requirements to hardware/software; secure architecture and design reviews; secure coding; integrate SAST/DAST/SCA/SBOM tooling; execute verification including fuzz and penetration testing.
Deliverables: cybersecurity requirement specifications; design and threat-model artefacts; verification and pentest reports; SBOM.
Phase 5 — Validate and release (Clauses 11 & 6)
Activities: vehicle/system-level validation; residual-risk evaluation; compile the Cybersecurity Case; conduct the independent Cybersecurity Assessment; authorise release for post-development.
Deliverables: validation report; residual-risk statement; cybersecurity case; assessment report; release record.
Phase 6 — Produce, operate and sustain (Clauses 8, 12, 13, 14 & R156)
Activities: implement the production control plan; stand up PSIRT and monitoring; establish incident response and OTA/SUMS; plan end-of-support and decommissioning; run continual vulnerability management.
Deliverables: production control plan; PSIRT/IR playbooks; SUMS certificate; vulnerability register; end-of-support policy.
Phase 7 — Certify and maintain
Activities: pre-audit gap review; support the CSMS/SUMS certification audit by the Technical Service; support each vehicle type approval; establish continuous surveillance to keep certificates valid (max 3-year cycle).
Deliverables: audit-ready evidence pack; CSMS and SUMS certificates; type-approval dossiers; surveillance plan.
Capability / maturity model
While ISO 21434 itself expresses rigour through Cybersecurity Assurance Levels (CAL 1-4) rather than an organisational maturity scale, CyberSigma applies a complementary five-level capability model — aligned with ASPICE and CMMI thinking — to benchmark an organisation's readiness to operate the CSMS consistently. The two are shown together below.
| Level | Capability / assurance meaning |
|---|---|
| Level 0 — Incomplete | No defined cybersecurity process; activities ad hoc or absent; unable to meet R155. |
| Level 1 — Performed | TARA and basic work products produced on some projects, but reactively and inconsistently; no org-level CSMS. |
| Level 2 — Managed | Cybersecurity planned, resourced and tracked per project; CIAs in place; work products reviewed; CSMS drafted. |
| Level 3 — Established / Defined | Organisation-wide standard process deployed and tailored per project; competence and tool management operational; CSMS certifiable. |
| Level 4 — Predictable / Measured | Cybersecurity KPIs and metrics used to control process quality; quantitative risk trending; strong PSIRT and monitoring. |
| Level 5 — Optimising | Continuous improvement driven by field intelligence, red-teaming and lessons learned; threat-intel feeds back into TARA method. |
Cybersecurity Assurance Levels, the standard's own rigour scale, are derived from the impact rating of a threat scenario combined with the attack feasibility:
| CAL | Rigour of cybersecurity activities |
|---|---|
| CAL 1 | Lowest rigour — applies to low impact / low-effort-to-exploit scenarios; basic activities and reviews. |
| CAL 2 | Moderate rigour — increased analysis, verification and review depth. |
| CAL 3 | High rigour — extensive independent review, deeper testing (including penetration testing), stronger design controls. |
| CAL 4 | Highest rigour — most demanding activities, maximum independence and assurance for high-impact, feasible attacks (typically safety-critical). |
Assessment and audit approach
A formal ISO 21434 / R155 assessment follows a disciplined sequence. CyberSigma performs each step as either a readiness (gap) engagement or a mock certification audit.
- Define scope and objectives: fix the organisation (CSMS), the item/type, the lifecycle phases and the markets in scope; agree the assessment criteria against ISO 21434 clauses and R155 Annex 1/Annex 5.
- Assemble the assessment team with demonstrable independence from the engineering being assessed, and confirm competence.
- Review documentation: examine the cybersecurity policy, processes, plans, TARAs, cybersecurity case, verification and validation evidence, and CIAs.
- Conduct interviews and process walk-throughs: verify that documented processes are actually practised by engineers, PSIRT and management.
- Perform technical sampling: sample TARA quality, requirement traceability, test coverage, and review penetration-test and vulnerability-management evidence.
- Assess the type-level risk assessment against R155 Annex 5 for full threat coverage and adequate mitigations.
- Identify findings and classify by severity (major nonconformity, minor nonconformity, observation, opportunity for improvement).
- Rate maturity/capability and CAL adequacy; determine whether residual risk is acceptable.
- Report: issue the assessment report with findings, evidence references and a prioritised remediation roadmap.
- Agree corrective actions and re-verify closure; recommend for CSMS/type-approval certification once nonconformities are cleared.
- Establish surveillance: schedule periodic audits within the 3-year certificate validity to maintain conformity and address emerging threats.
Evidence request list
The following categorised evidence pack should be requested at the outset of any assessment.
- Governance: cybersecurity policy; org chart and RACI; competence matrix and training records; management-review minutes; internal audit reports.
- Process: cybersecurity rules and processes; tool management/qualification records; information-sharing (Auto-ISAC) evidence.
- Project management: project cybersecurity plans; tailoring records; release-for-production records.
- Supply chain: supplier capability evaluations; RFQ cybersecurity requirements; signed Cybersecurity Interface Agreements; joint work-product lists.
- Concept & TARA: item definitions; TARA reports; cybersecurity goals and concepts; CAL determinations; R155 Annex-5 coverage matrices.
- Development: cybersecurity requirement specifications; architecture/design and threat-model documents; traceability matrices; SBOMs; secure-coding guidelines.
- Verification & validation: SAST/DAST/SCA reports; fuzzing reports; penetration-test reports; requirement-based test coverage; validation and residual-risk reports.
- Cybersecurity case & assessment: the cybersecurity case; independent cybersecurity assessment report; independence declarations.
- Production: production cybersecurity control plan; key/secret provisioning and HSM records; end-of-line configuration lockdown evidence.
- Operations: PSIRT charter; incident response plans and tabletop records; vulnerability register; OTA/SUMS records; incident reporting logs to the Approval Authority.
- Regulatory: CSMS Certificate of Compliance; SUMS certificate; vehicle type-approval dossiers; RxSWIN records; end-of-support policy.
Roles and responsibilities
| Role | Cybersecurity responsibilities |
|---|---|
| Executive management / Board | Endorse cybersecurity policy, allocate resources, own residual risk acceptance at organisational level, conduct management review. |
| Cybersecurity Manager / Automotive CISO | Own the CSMS; define processes; ensure competence and tooling; authorise the cybersecurity case; interface with Approval Authority. |
| Project Cybersecurity Manager | Deliver the project cybersecurity plan; manage tailoring; ensure work products are produced and traced; compile the cybersecurity case. |
| TARA Analyst / Security Architect | Facilitate TARA; identify assets/threats; rate impact and feasibility; derive goals and CALs; design security architecture. |
| Cybersecurity Assessor | Perform the independent cybersecurity assessment; must be independent of the engineering team; recommend acceptance. |
| Development & Verification Engineers | Implement secure requirements; apply secure coding; run SAST/DAST/fuzz/pentest; resolve weaknesses. |
| PSIRT / Monitoring Lead | Operate continual monitoring, event evaluation, vulnerability management and incident response; report incidents. |
| SUMS / OTA Owner | Manage software update process, RxSWIN, update integrity, and R156 compliance. |
| Supplier Quality / Procurement | Evaluate supplier capability, embed cybersecurity in RFQs, manage CIAs. |
| Approval Authority / Technical Service | Audit CSMS/SUMS, review type risk assessment, issue certificates and type approvals. |
KPIs to track
- Percentage of in-scope items/components with a completed and reviewed TARA.
- Number of open cybersecurity risks by risk value (1-5) and mean time to treat.
- Requirement-to-test traceability coverage (percentage of cybersecurity requirements with passing verification).
- Penetration-test findings by severity and mean time to remediate.
- Vulnerability management: mean time to triage and mean time to remediate (MTTR) field vulnerabilities.
- Number of security incidents detected, contained and reported within regulatory timelines.
- OTA campaign success rate and time from patch availability to fleet deployment.
- Percentage of engineers meeting the required competence level (training completion).
- Supplier cybersecurity capability scores and percentage of parts covered by signed CIAs.
- R155 Annex-5 threat coverage (percentage of catalogue threats with evidenced mitigations).
- Internal audit nonconformities: count, severity, and closure rate.
- CSMS/SUMS certificate validity runway (days to expiry) and surveillance-audit compliance.
Readiness checklist
- A cybersecurity manager is appointed and an executive-endorsed cybersecurity policy is published.
- Organisation-wide cybersecurity processes are documented and integrated with the quality/ASPICE/ISO 26262 system.
- A competence matrix and training programme are in place and evidenced.
- Tool management and information-sharing (Auto-ISAC) arrangements are operational.
- Every in-scope project has a cybersecurity plan with assigned responsibilities and justified tailoring.
- Suppliers are capability-assessed and Cybersecurity Interface Agreements are signed.
- Item definitions and TARAs are complete, with cybersecurity goals, CALs and R155 Annex-5 coverage.
- Cybersecurity requirements are traced to design, implementation and verification.
- SAST/DAST/SCA, fuzzing and penetration testing are performed and findings remediated; an SBOM is maintained.
- Vehicle-level validation is complete and residual risk is formally accepted.
- A cybersecurity case is compiled and an independent cybersecurity assessment is passed.
- A production cybersecurity control plan protects keys, secrets and provisioning.
- PSIRT, continual monitoring, incident response and reporting to the Approval Authority are operational.
- A SUMS is in place with RxSWIN management and update integrity protection (R156).
- End-of-support and decommissioning provisions are defined and communicated.
- CSMS and SUMS certificates are obtained/valid and each vehicle type approval dossier is complete.
Common gaps
- TARA treated as a one-off tick-box artefact rather than a living analysis updated with new threats and design changes.
- Cybersecurity bolted on late in development instead of shift-left integration at concept phase — leading to expensive rework.
- Weak supply-chain governance: missing or vague Cybersecurity Interface Agreements, and Tier-n suppliers unable to provide assurance evidence.
- No genuine independence in the cybersecurity assessment — the assessor reports to the same manager as the development team.
- Incomplete R155 Annex-5 coverage: threats listed in the catalogue with no traceable mitigation or evidence.
- PSIRT and continual monitoring exist on paper but lack real feeds, staffing or a tested incident-response playbook.
- SUMS/OTA integrity gaps: updates not cryptographically signed, no RxSWIN discipline, or no rollback protection.
- Poor requirement-to-test traceability, so verification cannot demonstrate that cybersecurity goals are actually met.
- Missing tool confidence/qualification, allowing security-analysis tools to silently miss defects.
- Production secrets (keys, credentials) handled insecurely, or debug/diagnostic access left enabled at end-of-line.
- Under-resourced competence management: engineers doing cybersecurity work without training or defined qualification.
- Certificate lapse risk: no surveillance plan to keep the 3-year CSMS/SUMS certification valid, risking sales suspension.
ISO 21434 mapped to other frameworks
ISO 21434 does not exist in isolation. It interlocks with functional safety, IT security, privacy and quality regimes. The mapping below helps organisations reuse existing controls and avoid duplicated effort.
| Framework | Relationship to ISO 21434 / R155 |
|---|---|
| UNECE R155 (CSMS) | The legal mandate; ISO 21434 is the recognised engineering method to satisfy it. Annex 5 threat catalogue drives the type risk assessment. |
| UNECE R156 (SUMS) | Companion regulation for software updates; ISO 21434 Clauses 8/13 and update-integrity design feed the SUMS. |
| ISO 26262 (Functional Safety) | Shares the same V-model lifecycle and independence concepts; the 'S' in the TARA impact rating (S/F/O/P) links directly to ASIL/safety goals; often run jointly. |
| ASPICE (Automotive SPICE) | Process capability model for automotive software; ISO 21434 activities are assessed for capability using ASPICE-style dimensions. |
| ISO/IEC 27001 | Enterprise ISMS; covers IT/back-end and corporate security. R155 back-end and production security align with 27001 Annex A controls; can host the CSMS's IT elements. |
| IEC 62443 | OT/industrial security; relevant to production plants and charging infrastructure interfacing with vehicles. |
| NIST CSF / NIST 800-53 | Function-based (Identify-Protect-Detect-Respond-Recover) reference for monitoring, PSIRT and incident response maturity. |
| NIST SSDF (SP 800-218) | Secure software development practices map onto ISO 21434 Clause 10 secure implementation and Clause 8 vulnerability management. |
| ISO 24089 | Road-vehicle software-update engineering standard; the engineering counterpart to R156/SUMS. |
| GDPR / DPDP Act (India) | Connected-vehicle personal data (location, telematics) triggers privacy obligations that feed the 'P' in TARA impact rating. |
| Auto-ISAC Best Practices | Industry information-sharing and best-practice guides supporting Clause 5 information sharing and Clause 8 monitoring. |
Frequently asked questions
Need help with ISO 21434?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.