ISO/SAE 21434 Work Products That Survive Audit

Work products are the compliance language

ISO/SAE 21434 structures cybersecurity engineering across the lifecycle. For OEM and supplier programs under UN R155 pressure, the standard’s value is not the clause list — it is the set of work products that make risk decisions, design controls, and verification results reviewable.

Auditors and technical services do not need every optional template filled. They need a coherent chain: what is in scope, what can go wrong, what you decided to do about it, how that shows up in design, and how you proved it.

Concept-phase anchors

Early work products prevent late rework. Weak item definition is the most expensive failure mode: teams argue about whether cloud backends, mobile apps, or diagnostic tools are “in the item” after TARA is already frozen.

• Item definition: functions, architecture sketch, trust boundaries, assumptions, and out-of-scope interfaces stated explicitly
• Cybersecurity goals / claims derived from damage scenarios, not from a generic control checklist
• Cybersecurity concept that maps goals to high-level controls and ownership (OEM vs supplier vs shared)
• Preliminary architecture views that show external interfaces and privileged paths (diagnostics, OTA, backend APIs)

TARA as a living engineering artifact

Threat Analysis and Risk Assessment should be usable by architects and test leads, not only by the cybersecurity specialist who wrote it. Each retained risk needs a treatment decision; each treatment needs a hook into requirements or accepted residual risk with management visibility.

When variants, features, or connectivity packages change, TARA deltas matter. A static PDF from concept freeze that ignores production architecture drift will not survive a serious review.

Product development work products that carry weight

Once goals exist, the useful trail is requirements → design → implementation evidence → verification.

• Cybersecurity requirements allocated to components, with unique IDs and verification methods
• Design evidence for high-risk controls: authentication flows, key storage, gateway policy, secure boot, update verification
• Interface agreements with suppliers that state cybersecurity responsibilities and evidence expected at delivery
• Integration and verification plans that include negative tests, not only happy-path functional checks
• Vulnerability analysis / testing reports tied back to TARA scenarios and requirement IDs

What “traceability” means in a real review

Traceability is not a giant matrix nobody maintains. It is the ability to pick a high-severity threat scenario and walk to the treatment, the requirement, the design element, and a test result — or to a documented residual risk acceptance.

Tooling helps, but inconsistent IDs, copy-pasted requirements, and tests that never mention the control under attack are what fail gate reviews. Prefer fewer, sharper requirements with real V&V over hundreds of vague “shall be secure” lines.

Production and post-development evidence

21434 does not stop at SOP. Production controls (secure flashing, key provisioning, configuration enforcement) and operations (monitoring inputs, vulnerability handling, update capability, end-of-support decisions) need owners and records.

If your CSMS/SUMS processes claim post-production capability, the work products should show those processes were applied to this item — not only that a corporate procedure exists.

A practical minimum set before a tough gate

Before a customer, authority, or internal homologation gate, most programs need at least: a current item definition, a TARA aligned to the architecture under review, cybersecurity goals and allocated requirements, design evidence for critical controls, verification results for those controls, supplier evidence for outsourced high-risk parts, and a clear post-SOP ownership map for vulnerabilities and updates.

Everything else is useful scaffolding. Without that chain, additional templates rarely help.

Bottom line

ISO/SAE 21434 work products survive audit when they tell one story end to end. Build the chain early, keep IDs stable, test the controls that matter, and treat post-development evidence as part of the same argument — not a separate binder.