Inside ISO WIZ: A Platform Walkthrough for Safety Engineers

What Does a Unified Compliance Platform Actually Look Like?

The case for harmonizing ISO 26262, SOTIF, ISO 21434, and Automotive SPICE into a single workflow is conceptually compelling. The practical question is: what does that actually look like in a tool? How does software translate "shared traceability across four standards" into something a safety engineer uses on a Tuesday afternoon?

This is a walkthrough of the ISO WIZ platform — not a marketing overview, but a screen-by-screen look at how the unified workflow operates in practice.

Starting Point: The Dashboard

The dashboard is the control surface for an organization's entire compliance posture across all active standards.

At the top level, four status tiles show the live state of your program: Standards Active, Unified Projects, Team Members, and Unified Compliance percentage. Below those, the Unified Standards Progress panel tracks all four standards simultaneously:

• ISO 26262 (Functional Safety)
• ISO 21434 (Cybersecurity)
• ISO 21448 (SOTIF)
• ASPICE (Process Maturity)

Each shows a progress percentage and status. When a project is active, these track in real time as work products are completed and reviewed. The Recent Activity feed shows a timestamped log of every change across the project — who changed what, when, and which standard it affected.

The nav bar exposes the platform's main modules: Projects, Analytics, Audit Trail, Standards Engine, and Integrations.

Creating a Project: Standards as Overlays

When you start a new project, the first choice is your functional safety domain: Passenger Car, Truck/Bus, Motorcycle, or Semiconductor / SEooC. Each domain configures the lifecycle with the appropriate compliance logic — ASIL-based risk assessment for passenger cars, MSIL for motorcycles, SEooC-specific assumptions for semiconductor components.

The second step is standards selection. This is where ISO WIZ makes its architecture explicit. Each standard is described not as a separate silo but as an overlay that injects requirements into a single shared lifecycle:

• ISO 26262 injects: Safety Plan & Item Definition, HARA & Safety Goals, Functional Safety Concept, Technical Safety Requirements, and 2 more
• ISO 21434 injects: Asset Identification, Threat Analysis (TARA), Security Goals & Requirements, Cybersecurity Verification, and 2 more
• ISO 21448 SOTIF injects: Intended Function Description, Triggering Conditions, Functional Insufficiencies, Known/Unknown Unsafe Scenarios, and 2 more
• ASPICE injects: Work product presence checks, Review & approval records, Bidirectional traceability, Process completeness indicators, and 2 more

Select all four and the platform shows you what happens next: "A single V-Model lifecycle is created with your selected domain context. Selected standards inject required work products, trace relationships, and exit criteria. Gate validation enforces compliance before step progression. Audit readiness is a natural byproduct of the process."

That last line is the key design principle. Audit readiness isn't a phase or a sprint — it's the continuous state of a project that's been built on the platform from day one.

The Unified Lifecycle Wizard

After selecting all four standards, the Unified Lifecycle Wizard opens with 123 work products spanning the full V-Cycle. The left sidebar organizes them by phase:

Each phase is broken down into individual work product steps, each tagged with the standard it belongs to. In the Management phase alone, ISO 26262 steps (Project Context, Safety Management Plan, Safety Lifecycle Tailoring, Tool Qualification Plan) appear alongside ISO 21434 steps (Cybersecurity Management Plan, Cybersecurity Roles & Responsibilities, Continuous Cybersecurity Activities) — all in a single sequenced list, not two parallel workstreams.

Every work product shows:

• The ISO standard clause reference it satisfies
• Its current version (starting at v0.0.1, incrementing with each revision)
• Edit status and review workflow state
• Dependencies (which prior work products it requires)
• History (every previous version with author and timestamp)
• Change Requests (formal change management linked to this artifact)

The HARA (Hazard Analysis & Risk Assessment) lives in the Concept phase. Its metadata immediately shows the cross-standard integration: it's required for Safety Goals and ASIL Classification, with dependencies back to Item Definition — and if you have SOTIF active, the same Item Definition also feeds the SOTIF Intended Function Description, which the platform enforces at the data model level.

Dashboard Mode: The V-Cycle at a Glance

Toggling from Wizard to Dashboard mode gives you a bird's-eye compliance view. On the left, every step across all phases and all standards is listed with individual progress bars. On the right, a compliance panel tracks:

Parts Compliance (ISO 26262):

• Part 2 Management: 0/28
• Part 3 Concept: 0/18
• Part 4 System: 0/18
• Part 5 Hardware: 0/9
• Part 6 Software: 0/11
• Part 8 Supporting: 0/11

Compliance Alerts surfaces issues immediately — not at export time. On a fresh project, it flags "Competence Evidence Missing (Clause 2.5.1)" before any work has been done. This is the gate validation system in action: the platform knows what ISO 26262 Part 2 requires for organizational competence documentation and surfaces the gap proactively.

Audit Readiness is tracked as a live metric. Rather than being assessed at the end of a program, it's calculated continuously from work product completion, review status, and traceability coverage.

The Standards Engine: 633 Clauses, 1013 Rules, 328 Relationships

The Standards Engine is ISO WIZ's compliance knowledge base — the structured representation of all four standards that drives the platform's automated guidance.

The headline numbers:

Each standard has its own engine dashboard:

The ISO 26262 engine carries an Engine Valid status — meaning the clause structure, rule mapping, and relationship graph have been verified against the published standard. The same Engine Valid badge appears for all four standards.

The ISO 26262 engine's individual dashboard shows 329 clauses mapped to 80 artifacts with 93% coverage — the gaps representing areas where the standard's requirements have been identified but workflow steps haven't yet been assigned.

Cross-Standard Traceability: The 328 Relationships

The Cross-Standard Traceability view is where the integration becomes most visible. Six relationship categories cover every pairwise connection between the four standards:

Safety → Security (ISO 26262 ↔ ISO 21434): 12 touchpoints

Shared safety/security goals and HARA→TARA mapping. These are the points where a hazardous event in the safety analysis corresponds to a threat scenario in the cybersecurity analysis — where an attacker exploiting a vulnerability could produce a harm outcome that functional safety also needs to address.

Safety → SOTIF (ISO 26262 ↔ ISO 21448): 8 touchpoints

Hazard analysis overlap and functional insufficiency vs. failure boundary. These are the scenarios where the same outcome (e.g., unintended braking) can result from a systematic fault (ISO 26262 domain) or a performance limitation without any fault (SOTIF domain). The touchpoints define how the two analyses hand off responsibility at the boundary.

Security → SOTIF (ISO 21434 ↔ ISO 21448): 5 touchpoints

Attack scenarios as triggering conditions for SOTIF. An adversarial input that causes a sensor to produce plausible-but-wrong output is simultaneously a cybersecurity threat and a SOTIF triggering condition. These 5 touchpoints map those dual-domain scenarios.

Safety → Process (ISO 26262 ↔ ASPICE): 15 touchpoints

SWE/SYS process compliance for safety-critical development. The largest relationship set — 15 points where ISO 26262 work products directly satisfy ASPICE process capability evidence requirements.

Security → Process (ISO 21434 ↔ ASPICE): 7 touchpoints

SUP.8 configuration management requirements for cybersecurity artifacts — ensuring that TARA versions, cybersecurity goals, and security controls are managed under the same change control framework as safety work products.

SOTIF → Process (ISO 21448 ↔ ASPICE): 4 touchpoints

Verification process requirements for SOTIF scenario validation — linking ASPICE's SWE.4/SWE.5 testing processes to SOTIF validation evidence.

The Audit Trail: Immutable, Forensic-Grade

The Audit Trail module is scoped per-project and provides an immutable event log with forensic-grade traceability. Every work product modification, every review action, every change request approval is timestamped, attributed to a named user, and permanently recorded.

The practical significance for safety programs: an ISO 26262 assessment doesn't just ask to see the work products — it asks who approved them, when, under what change control, and whether the approval predates any subsequent modification. The ISO WIZ Audit Trail answers all of these questions from a single screen, with an Export JSON option for evidence submission.

What the Numbers Mean for Your Program

Running a passenger car program with all four standards active on ISO WIZ means working within a system that has:

• 1,013 rules continuously checking your work products against standard requirements
• 328 pre-mapped relationships ensuring that a change in one standard's analysis propagates correctly to the others
• Gate validation at every step, so you cannot progress to safety goals before the HARA is complete, cannot finalize the safety concept before safety goals are established, and cannot begin hardware safety analysis before the functional safety concept exists

The alternative — four separate tools, four separate teams, and 328 relationships maintained manually in reconciliation spreadsheets — is what most automotive safety programs are running today.

The platform isn't a shortcut. It's the same rigor, with the connections made by the tool instead of by heroic individual effort.