One Platform, Four Standards: How ISO WIZ Harmonizes ISO 26262, SOTIF, ISO 21434, and ASPICE

The Four-Standard Problem Nobody Talks About

Modern automotive programs don't run on one standard. They run on four simultaneously.

ISO 26262 covers functional safety — the systematic failures that can kill. ISO 21448 (SOTIF) covers the intended functionality failures that AI and autonomous systems introduce. ISO 21434 covers cybersecurity — the attack surfaces that an adversary can exploit to undermine safety. Automotive SPICE covers process capability — the organizational evidence that you can actually build what you claim to build.

A vehicle program ships when all four are satisfied. But in most organizations, each standard lives in a different tool, maintained by a different team, with no shared data model between them.

That fragmentation is where risk hides.

What Siloed Standards Actually Cost You

Consider a scenario: your safety team identifies a new hazardous event during HARA that involves a camera-based perception function failing in adverse lighting. Under ISO 26262, they derive a safety goal. Under SOTIF, the exact same scenario — camera degradation in rain — should trigger a triggering condition and a SOTIF scenario analysis. Under ISO 21434, an adversary who can inject spoofed camera data exploits the same sensor pathway.

In a siloed tool environment:

• The ISO 26262 team writes the safety goal in their requirements tool
• The SOTIF team writes the triggering condition in a separate spreadsheet
• The cybersecurity team identifies the threat in a separate TARA document
• Nobody connects the three — because there's no mechanism to

That connection is exactly what an auditor will ask about. "How does your cybersecurity TARA relate to your SOTIF scenario analysis? How does your SOTIF residual risk feed into your functional safety concept?" Without cross-standard traceability, the answer is manual reconstruction from memory.

The Hidden Duplication Tax

Every standard requires some form of:

• Item definition / system description
• Hazard or risk identification
• Goal/objective derivation
• Verification and validation evidence

In siloed tools, these artifacts are created four times, maintained four times, and reviewed four times. When the system architecture changes — a new sensor added, a software partition moved — the update has to be tracked across four separate data stores.

One estimate from a mid-size Tier 1 supplier: roughly 30% of a safety engineer's time on a complex ADAS program is spent on cross-standard reconciliation — manually checking that the cybersecurity TARA, the SOTIF analysis, and the functional safety concept don't contradict each other.

That's not engineering. That's administration.

What Harmonization Actually Means

Harmonization isn't running four tools through a shared file server. It means:

Shared item definition. The system description — item boundaries, interfaces, operational modes — is defined once and referenced by all four standards. When it changes, all four analyses update from a single source.

Cross-standard traceability. A safety goal in ISO 26262 links bidirectionally to the SOTIF scenario that motivated it and the cybersecurity threat that could trigger the same hazardous event. Traceability gaps surface in all directions.

Unified verification. Test cases and V&V evidence reference both the safety requirement they satisfy and the standard clause they address — whether that's an ISO 26262 TSC, a SOTIF validation scenario, an ISO 21434 cybersecurity control, or an ASPICE process output.

Single process capability baseline. ASPICE process capability evidence — design documents, review records, test reports — is generated from the artifacts the safety and cybersecurity teams are already producing, not assembled separately.

How ISO WIZ Implements This

ISO WIZ is built around a shared data model that spans all four standards from the ground up:

• ISO 26262: Full lifecycle from project context and DIA through HARA, ASIL determination, FSC, TSC, FMEA/FMEDA, safety case, and verification planning
• ISO 21448 SOTIF: Triggering condition identification, scenario categorization (known/unknown), SOTIF evaluation, residual risk assessment, and validation completeness argument
• ISO 21434: TARA (Threat Analysis and Risk Assessment), threat identification, attack path analysis, cybersecurity goals, cybersecurity concept, and security controls
• Automotive SPICE PAM 3.1: Process capability assessment mapped against the work products and activities already being generated by the safety and cybersecurity workflows

Every artifact links to every other relevant artifact across standards. A SOTIF triggering condition links to the ISO 26262 hazardous event that shares the same operational scenario. A cybersecurity threat links to the safety goal it could undermine. An ASPICE process output links to the review records generated during ISO 26262 artifact approval.

When you change something in one standard, the cross-standard gap checker tells you what downstream artifacts in other standards need review.

The Audit Story

When an assessor asks "show me how your cybersecurity analysis connects to your functional safety concept," the answer isn't a manually assembled reconciliation spreadsheet. It's a live traceability view that shows the threat, the safety goal it maps to, the hazardous event, and the verification evidence — all in one screen, all with timestamps and authorship.

That's what harmonization looks like in practice.