The result, in most development organizations, is four parallel documentation streams that share terminology but not data — and that diverge silently over the course of a multi-year program.
What Harmonization Actually Means
Harmonization is not putting four standards in the same folder. It is establishing the shared data model that allows work products from each standard to reference each other as live, traceable links rather than copied text.
The key shared objects:
The item. Every standard begins with a definition of what is being analyzed. ISO 26262 calls it the item. ISO 21434 calls it the item. SOTIF calls it the system under analysis. ASPICE calls it the product. In a harmonized program, this is one artifact, not four descriptions of the same system in four documents.
The function. An ADAS lane-keeping function is simultaneously a safety-relevant function (ISO 26262 HARA), a function with intended functionality limitations (SOTIF triggering conditions), an asset with a cybersecurity attack surface (ISO 21434 TARA), and a software function with ASPICE process requirements (ASPICE SWE). One function, four analytic perspectives, one data object.
The requirement. A safety requirement derived from a safety goal becomes a functional safety requirement (ISO 26262), a performance requirement bounding a triggering condition (SOTIF), a security requirement protecting a safety-relevant signal (ISO 21434), and a software requirement with acceptance criteria (ASPICE SWE.1). Four standards, one requirement specification — if the data model enforces the links.
The Cross-Standard Interaction Map
The interactions between the four standards are not random. They follow predictable patterns that can be mapped and managed.
This map has 18 cross-standard dependencies listed, and this is not exhaustive. In a program without explicit management of these interactions, each dependency is a potential source of silent inconsistency.
The ASPICE Integration Point
ASPICE is often treated as a process audit layer that sits above the technical work — something the quality team manages separately. This is a mistake.
ASPICE PAM 3.1 process areas directly reference the technical work products of the other standards:
- SWE.1 (Software Requirements Analysis) expects software requirements that are traceable to system requirements — which, in an ISO 26262 program, means traceable to safety goals
- SWE.2 (Software Architectural Design) expects design decisions to be justified against requirements — which, in a SOTIF program, means the algorithm architecture must be justified against performance requirements derived from triggering conditions
- SWE.3 (Software Detailed Design and Unit Construction) expects code to be traceable to design — and for ASIL software, that includes MISRA compliance, complexity metrics, and coverage requirements from ISO 26262-6
When ASPICE is managed separately, the assessor asks for evidence of SWE.1 traceability and the engineering team produces a traceability matrix that was generated after the fact, mapping whatever requirements they have in their tool to whatever code they can find. It is not wrong, but it is not what ASPICE intended.
When ASPICE is integrated with ISO 26262, the traceability exists in the development data itself: safety goals → functional safety requirements → software safety requirements → software architecture → code. The ASPICE SWE.1 evidence is the same artifact as the ISO 26262 software requirements specification, evaluated against ASPICE process criteria.
The Change Propagation Problem
The most persistent failure mode in multi-standard programs is change propagation. An engineering decision changes one artifact; the downstream implications for the other standards are not tracked.
Example sequence:
- The hardware team changes the power supply architecture to reduce cost. A shared 5V rail is split into two independent 5V rails.
- The change is reviewed and approved by the hardware team.
- The ISO 26262 FMEDA is updated to reflect the new independence between the two rails.
- Nobody updates the ISO 21434 TARA, which had assumed a shared power supply as a potential CCF attack vector (an attacker who can cause a power surge to one channel can affect both).
- Nobody updates the ASPICE SWE.2 design justification, which cited the hardware architecture version that no longer exists.
- Six months later, the ISO 21434 assessor asks why the TARA attack feasibility rating for the power surge scenario is lower than expected, and the team discovers the TARA references an outdated architecture.
In a harmonized program with live cross-standard links, step 3 automatically flags the TARA and the ASPICE design justification for review. The engineer who approved the FMEDA update sees a list of downstream items that reference the changed artifact. The change propagation is tracked, not lost.
ISO WIZ: Built for This
ISO WIZ was designed from the ground up for the four-standard automotive compliance reality. It is not a generic requirements management tool with automotive templates added. It is a purpose-built platform where the data model reflects the actual structure of ISO 26262, SOTIF, ISO 21434, and ASPICE — including their cross-standard dependencies.
The shared item definition is a first-class data object, not a document. The HARA severity rating is a field that feeds directly into TARA impact assessment. The safety mechanism list from the functional safety concept automatically populates the asset candidates in the TARA module. ASPICE work product evidence is linked to the engineering artifacts it evidences, not maintained as a separate checklist.
When any artifact changes, ISO WIZ generates a change impact report across all four standards — showing which downstream work products reference the changed artifact, which cross-standard links may now be inconsistent, and which engineer is responsible for each review action.
For programs that are currently managing these standards in separate tools or spreadsheets, the first visible benefit is not better analysis — it is the elimination of the coordination overhead that is currently absorbed by manual cross-team review meetings, impact assessment emails, and last-minute document reconciliation before assessments.
The deeper benefit is the audit trail: every link, every change, every review action is recorded. When an assessor asks "how do you know your TARA impact ratings are consistent with your HARA severity ratings?" the answer is a live traceability matrix, not a PowerPoint slide built the week before the assessment.