Every ISO/SAE 21434 Work Product, Demystified: The Complete Checklist for UNECE R155 Readiness

Why “work product,” not “document,” is the right word

ISO/SAE 21434 does not use the word “document.” It uses “work product.” The distinction matters.

A document is a file. A work product is a piece of evidence that a specific cybersecurity activity has been performed. A work product may take the form of a document, a database entry, a configuration file, a git commit, a signed attestation, or a combination. What makes it a work product is the traceability — you can point an auditor to it and demonstrate which clause mandates it, which activity produced it, and which role signed off.

UNECE R155 type-approval audits are defended in this vocabulary. Assessors ask for “the release recommendation” and expect WP-06-04. They ask for “your TARA” and expect the set of eight Clause 15 artefacts plus the overall WP-09-02. Teams that think in terms of documents — “we have a cybersecurity manual PDF” — routinely fail on traceability questions they should pass.

This post walks through the full set of ISO/SAE 21434 lifecycle work products, grouped by clause, with the failure modes we see most often in the field.

The WP-XX-YY convention and why sources disagree on the count

ISO/SAE 21434 Annex A Table A.1 is the authoritative list. Each work product has an identifier of the form WP-XX-YY, where XX is the clause number (05 through 15) and YY is the sequential position within that clause.

Counting unique identifiers in Table A.1 yields 42 work products:

• Clause 5: 5 (WP-05-01 to WP-05-05)
• Clause 6: 4 (WP-06-01 to WP-06-04)
• Clause 7: 1 (WP-07-01)
• Clause 8: 6 (WP-08-01 to WP-08-06)
• Clause 9: 7 (WP-09-01 to WP-09-07)
• Clause 10: 7 (WP-10-01 to WP-10-07)
• Clause 11: 1 (WP-11-01)
• Clause 12: 1 (WP-12-01)
• Clause 13: 1 (WP-13-01)
• Clause 14: 1 (WP-14-01)
• Clause 15: 8 (WP-15-01 to WP-15-08)

Total: 5 + 4 + 1 + 6 + 7 + 7 + 1 + 1 + 1 + 1 + 8 = 42.

Secondary training material often reports 33 or 36. Both undercounts trace to the same mistake: collapsing Clause 15's eight TARA method work products into a single “TARA” item, or merging Clause 8's six continual cybersecurity activities into a single “vulnerability management” item. Neither collapse is supported by the standard. Annex A lists them individually, with individual identifiers.

Some sub-clauses within the standard reference the same work product from multiple angles — for instance, WP-05-01 (Cybersecurity policy, rules and processes) is referenced in five different organisational sub-clauses, 5.4.1 through 5.4.6. These are not five work products. They are one work product referenced five times. The identifier is the source of truth.

Clause 5 — Organisational cybersecurity management: your CSMS foundation

Clause 5 establishes the organisational foundation of the Cybersecurity Management System (CSMS). Without a defensible Clause 5 baseline, nothing downstream passes a UNECE R155 audit.

WP-05-01 — Cybersecurity policy, rules and processes. The top-level document suite that defines how the organisation governs cybersecurity. Policy statements, role definitions, process descriptions. Audit expectation: this is signed by executive leadership, reviewed annually, and traceable to every downstream activity.

WP-05-02 — Evidence of competence management, awareness management and continuous improvement. Training records, competency matrices, awareness programme attendance, continuous-improvement retrospectives. Audit expectation: individual engineers working on ASIL/CAL-classified items can demonstrate the specific training they received for that role.

WP-05-03 — Evidence of the organisation's management systems. The information security management system (typically ISO/IEC 27001), the quality management system (typically ISO 9001), and their interaction with the CSMS. Audit expectation: the CSMS is integrated with the ISMS and QMS, not a parallel paper exercise.

WP-05-04 — Evidence of tool management. Configuration management of engineering tools, including the security analysis tools, code analysis tools, and verification tools used in development. Audit expectation: tool versions are pinned, tool outputs are reproducible, and tool errors are tracked.

WP-05-05 — Organisational cybersecurity audit report. An independent annual audit of the CSMS against the organisation's own policy and ISO/SAE 21434 requirements. Audit expectation: the auditor is independent of the team being audited, findings are tracked to closure, and the report is retained.

Common failure: The WP-05-05 audit is performed by the same team that wrote the policy. Independence is a hard requirement — assessors will question this and a finding is likely.

Clause 6 — Project-dependent cybersecurity management: the type-approval bridge

Clause 6 governs how a specific vehicle programme or component programme applies the CSMS. Four work products, all critical for R155.

WP-06-01 — Cybersecurity plan. The project-level plan listing all cybersecurity activities, responsibilities, timelines, and deliverables for this specific item. Audit expectation: traceable to the item definition, maintained throughout development, and reviewed at project gates.

WP-06-02 — Cybersecurity case. The progressive argument that the item is adequately cybersecure, assembled from TARA outputs, verification evidence, validation results, and rationale. The cybersecurity case is not written at the end — it is built throughout development and closed at release.

WP-06-03 — Cybersecurity assessment report. An independent assessment of whether the cybersecurity case is credible. The assessor examines evidence, cross-checks argumentation, identifies gaps, and issues a formal finding.

WP-06-04 — Release for post-development report. The formal recommendation to release the item for production or post-development phases, signed by an authorised role, based on the cybersecurity case and assessment report.

Common failure: The cybersecurity assessment (WP-06-03) is performed by someone who reports to the project manager. Clause 6.4.8 explicitly requires independence. Assessors look for formal independence criteria — separate reporting line, different budget authority, written assessment charter. Shared lunch breaks do not invalidate independence; shared performance reviews do.

Clause 7 — One agreement, enormous consequences

Clause 7 defines distributed cybersecurity activities — the cybersecurity handoff between OEMs, Tier-1 suppliers, Tier-2 suppliers, and service providers. It has exactly one work product.

WP-07-01 — Cybersecurity Interface Agreement (CIA). The bilateral agreement between two organisations in the supply chain that defines which cybersecurity responsibilities sit with which party. The CIA includes a RASIC matrix (Responsible, Accountable, Supporting, Informed, Consulted) across every cybersecurity activity in the item lifecycle.

One work product. Massive blast radius. Every OEM–Tier-1 handoff needs one. Every Tier-1–Tier-2 handoff needs one. A single ECU delivered from a Tier-2 through a Tier-1 to an OEM typically involves two CIAs. Missing or vague CIAs are one of the most common audit findings in CSMS assessments because they ripple — a gap in a Tier-2 CIA creates an ambiguity that propagates all the way up to the OEM's TARA.

Common failure:The CIA says “Supplier is responsible for cybersecurity of the delivered component” without specifying which activities, which work products, which SLAs for incident response, or which data sharing. Assessors read these as non-agreements.

Clause 8 — From CVE feed to field fix

Clause 8 defines continual cybersecurity activities — the operational work that never stops once an item is in the field. Six work products form a vulnerability management pipeline.

WP-08-01 — Sources for cybersecurity information. The curated list of inbound feeds: NVD, MITRE CVE, OEM security advisories, coordinated disclosure partners, internal red-team findings, threat intelligence subscriptions.

WP-08-02 — Triggers. Defined conditions that cause the monitoring process to escalate an incoming information item to an event. A CVE matching a component in the bill of materials is a trigger. A research paper describing an attack on a protocol used by the item is a trigger.

WP-08-03 — Cybersecurity events. Items that have been triggered and are now under active review.

WP-08-04 — Weaknesses from cybersecurity events. Validated findings — the subset of events that represent real weaknesses in the item.

WP-08-05 — Vulnerability analysis. The analysis of each weakness to determine exploitability, impact, and affected vehicle types.

WP-08-06 — Evidence of managed vulnerabilities. Evidence that each vulnerability has been triaged, assigned a disposition (fix, compensating control, accept with rationale), and closed out with documentation.

This is a pipeline, not a set of documents. Information flows from WP-08-01 through WP-08-06 in sequence. Stages get collapsed at audit risk — if your process cannot distinguish between “event” and “weakness,” you cannot demonstrate that you are filtering noise from signal.

Common failure: Teams track CVEs in a spreadsheet and call that vulnerability management. The spreadsheet serves as WP-08-03 and WP-08-04 and WP-08-05 and WP-08-06 simultaneously. Auditors will ask to see the traceability between a specific CVE, its triage decision, the affected vehicle types, and the field action taken. A single spreadsheet rarely survives that question.

Clause 9 — The concept phase

Clause 9 covers the concept phase of a cybersecurity item — the point where the item is defined, its cybersecurity goals are established, and its cybersecurity concept is designed. Seven work products.

WP-09-01 — Item definition. The description of the item, its boundary, its external interfaces, its operational environment, and its pre-existing assumptions. This is the single most important upstream artefact in ISO 21434 — every TARA, every goal, every claim cascades from here.

WP-09-02 — TARA.Threat Analysis and Risk Assessment. The overall TARA output, which in ISO/SAE 21434's structure is the integrated result of the eight Clause 15 method work products (damage scenarios, assets, threat scenarios, impact ratings, attack paths, attack feasibility ratings, risk values, risk treatment decisions).

WP-09-03 — Cybersecurity goals.Top-level cybersecurity requirements derived from TARA — for example, “prevent unauthorised modification of vehicle firmware during operation.”

WP-09-04 — Cybersecurity claims.Claims about the item's cybersecurity that will be substantiated by evidence. Claims are the argument-building block of the cybersecurity case.

WP-09-05 — Verification report for cybersecurity goals. Evidence that the cybersecurity goals have been correctly decomposed and verified.

WP-09-06 — Cybersecurity concept. The high-level design approach — the cybersecurity controls, their allocation to the architecture, and the rationale.

WP-09-07 — Verification report of cybersecurity concept. Evidence that the cybersecurity concept correctly implements the cybersecurity goals.

Common failure: The item definition (WP-09-01) is treated as a system engineering leftover and handed to the cybersecurity team as-is. Cybersecurity has specific boundary and interface needs — external attack surfaces, trust boundaries, data classification — that system engineering item definitions typically miss. Reworking WP-09-01 as a joint artefact between system engineering and cybersecurity avoids the downstream rework.

Clause 10 — Product development

Clause 10 covers product development — the engineering work that turns the cybersecurity concept into an implementation. Seven work products.

WP-10-01 — Cybersecurity specifications. Detailed requirements for each cybersecurity control identified in the concept. For each control, the specification defines behaviour, performance bounds, interfaces, and verification criteria.

WP-10-02 — Cybersecurity requirements for post-development. Requirements that carry forward to production, operation, incident response, and decommissioning — key provisioning, secure manufacturing, field monitoring, update mechanisms.

WP-10-03 — Modelling, design, and programming languages and coding guidelines documentation. The documented language choices, design methodology, and coding standards used in the implementation. Typically references MISRA C:2012 or equivalent, plus any organisation-specific cybersecurity coding rules.

WP-10-04 — Verification report for the cybersecurity specifications. Evidence that the implementation correctly satisfies the cybersecurity specifications — unit tests, integration tests, static analysis, code review records.

WP-10-05 — Weaknesses found during product development. The bug list and their disposition — fixed, deferred with compensating control, accepted with rationale.

WP-10-06 — Integration and verification specification. The specification for how components are integrated and verified together, including test cases that exercise cybersecurity controls at integration points.

WP-10-07 — Integration and verification report. The results of executing the integration and verification specification, including penetration testing evidence at vehicle interfaces where required.

Common failure: Penetration testing at vehicle interfaces is treated as optional. R155 Annex 5 and ISO/SAE 21434 Clause 10 jointly require it. Submit without pen-test evidence at the CAN, Ethernet, OBD-II, BLE, and OTA boundaries and expect findings.

Clauses 11 through 14 — The lean clauses

Four clauses, one work product each, but each work product defends a lifecycle phase.

WP-11-01 — Validation report (Cybersecurity validation). Vehicle-level validation that the cybersecurity goals have been achieved in the integrated vehicle. This is the right-hand top of the V-model — the final demonstration that the cybersecurity concept, as implemented, works in the vehicle.

WP-12-01 — Production control plan. Cybersecurity controls in manufacturing — key injection, HSM provisioning, anti-tamper measures, software signing, serial number binding. Audit expectation: production-line operators cannot produce a vehicle without the cybersecurity bindings being performed.

WP-13-01 — Cybersecurity incident response plan. The plan for detecting, containing, investigating, remediating, and communicating cybersecurity incidents once the item is in the field. Audit expectation: the plan has been exercised through tabletop or live drills, with findings closed.

WP-14-01 — Procedures to communicate the end of cybersecurity support. How the organisation will notify vehicle owners, regulators, and downstream parties when cybersecurity support ends for a given vehicle type or software version.

Common failure: The incident response plan (WP-13-01) is written but never exercised. A tabletop exercise exposes the gaps — who has the decision authority to push an OTA fix at 3 AM, what does the escalation to the OEM PSIRT look like, how are regulators notified — that a desk-written plan misses.

Clause 15 — The eight TARA work products everyone under-counts

Clause 15 defines TARA methods. Eight work products, one per analytical step. Secondary sources collapse these into one. Annex A and Clause 15 do not.

WP-15-01 — Damage scenarios. The things that must not happen from the user, society, regulatory, or business perspective. Vehicle control loss. Vehicle immobilisation. Privacy breach. Cost fraud.

WP-15-02 — Assets with cybersecurity properties. The elements in the item that, if compromised, lead to damage scenarios. The assets are annotated with the cybersecurity properties (confidentiality, integrity, availability, authenticity, authorisation, non-repudiation) whose violation causes the damage.

WP-15-03 — Threat scenarios. The ways in which the cybersecurity properties of the assets could be violated.

WP-15-04 — Impact ratings with associated impact categories. Per damage scenario, the impact rating (severe, major, moderate, negligible) with associated impact categories (safety, financial, operational, privacy).

WP-15-05 — Attack paths. Concrete sequences of actions an attacker could take to realise the threat scenario.

WP-15-06 — Attack feasibility ratings. Per attack path, the feasibility rating based on attacker expertise, knowledge, time, equipment, and window of opportunity (commonly using the CVSS-inspired or JASO TP15002-inspired approaches).

WP-15-07 — Risk values. Per threat scenario, the risk value derived from impact and attack feasibility, typically via a lookup matrix.

WP-15-08 — Risk treatment decisions. Per risk, the treatment decision — avoid (remove the asset or feature), reduce (apply controls), share (transfer via contract or insurance), or retain (accept with rationale).

The eight outputs feed WP-09-02 (the overall TARA) and directly map to R155 Annex 5's threat and risk assessment requirements. A CSMS that submits “the TARA” as a single deliverable collapses the analysis chain. The standard structures the eight work products precisely so that each step is auditable and the reasoning is traceable. For the TARA methodology walkthrough, see our practical TARA guide.

The seven work products auditors ask for first

R155 type-approval assessments and ISO/SAE 21434 CSMS audits follow patterns. Assessors learn to ask for the work products that reveal the most about programme maturity fastest. Our experience with programmes across Europe, North America, Japan, and India puts these seven at the top of the list:

A programme that can produce all seven on demand, with clean traceability between them, passes the initial reading. Programmes that cannot produce one or more of these in coherent form face findings and typically a re-submission cycle.

Automating the evidence — where tools help, where humans must judge

Not every work product benefits equally from automation. The division is sharper than most teams assume.

Automation-friendly work products:

• WP-05-04 — Tool management evidence (pulled automatically from CI/CD, tool manifests, version logs)
• WP-08-01, WP-08-02, WP-08-03 — Monitoring feeds, triggers, events (continuous feed aggregation)
• WP-10-04, WP-10-06, WP-10-07 — Verification and integration test reports (test automation)
• WP-15-07 — Risk values (deterministic computation from impact and feasibility)

Judgement-dependent work products:

• WP-05-01 — Cybersecurity policy (human authorship, leadership sign-off)
• WP-06-02 — Cybersecurity case (argument construction)
• WP-06-03 — Cybersecurity assessment (independent judgement)
• WP-09-04 — Cybersecurity claims (argumentation)
• WP-11-01 — Validation report (engineering judgement on vehicle-level evidence)

A useful model: automation handles the work products that are structurally repeatable across projects and scale poorly under manual effort. Human judgement handles the work products where the exact context of this item, this programme, this release, matters. KAVACH, our AI-native CSMS platform, targets the automation-friendly layer — continuous generation of monitoring evidence, test reports, risk values, and TARA method artefacts — freeing engineering teams to focus on the work products that genuinely require human judgement.

A 90-day readiness path for OEMs and Tier-1s

Teams approaching their first ISO/SAE 21434 audit, or their first R155 type-approval submission, can use the following sequencing. It prioritises the work products that defend the audit while avoiding dependencies that stall the chain.

Days 1–15: Clause 5 baseline. Author or refresh WP-05-01 (policy). Confirm WP-05-03 (management systems integration) and WP-05-04 (tool management). Schedule independent audit cycle for WP-05-05.

Days 15–30: Clause 6 project setup. Author WP-06-01 (cybersecurity plan) for the specific programme. Identify independent assessor for WP-06-03.

Days 30–45: Clause 7 CIAs. Draft CIA templates. Execute with top three Tier-1 suppliers (or, for Tier-1s, with the OEM customer).

Days 45–60: Clause 15 TARA method. Establish the TARA methodology (which attack feasibility model, which risk matrix). Execute TARA for one representative vehicle type or ECU. This produces WP-15-01 through WP-15-08 and rolls up to WP-09-02.

Days 60–75: Clause 9 concept artefacts. Author WP-09-01 item definition, WP-09-03 goals, WP-09-06 concept. Start WP-09-04 claims.

Days 75–90: Clause 8 continual activities. Stand up the monitoring pipeline (WP-08-01 feeds, WP-08-02 triggers). Run one event through to WP-08-06 to prove the pipeline works.

By day 90, the programme has evidence for the seven audit-critical work products and functional pipelines for the rest. Full maturity on WP-10 series, WP-11-01, WP-12-01, WP-13-01, and WP-14-01 follows in the subsequent two quarters.

Frequently asked questions

By Shreyansh, Founder & CTO, Agnile Technologies.