The email arrives a few weeks before the assessment. Demonstrate that this safety requirement was implemented, tested, and released for this exact variant. The evidence exists. It sits in a requirements tool, a PLM system, a test bench log, a software repository, and a folder of meeting minutes. What follows in most engineering organizations is not an engineering effort. It is an evidence hunt, staffed by the senior people who can least afford it.
ISO 26262 compliance is the ability to demonstrate, with evidence, that the electrical and electronic systems of a road vehicle meet the standard's functional safety requirements: that hazards were analyzed, that safety requirements were derived and implemented, that they were verified by tests, and that the entire chain from hazard to test result is traceable. ASPICE asks a version of the same question from the process side. Both come down to the same underlying problem: can you produce the links between your engineering artifacts, or only the artifacts themselves?
This guide covers what the two frameworks actually ask for, why the evidence is so expensive to produce in a fragmented toolchain, and what changes when compliance evidence becomes a byproduct of connected engineering data instead of a recurring project.
The two frameworks are often named in the same breath, but they audit different things.
ISO 26262 is the functional safety standard for road-vehicle electrical and electronic systems. It classifies safety requirements by ASIL (Automotive Safety Integrity Level, from ASIL A up to ASIL D), and it expects a safety case: a structured argument, supported by evidence, that the vehicle's E/E systems are acceptably safe. The argument spans the lifecycle, from hazard analysis through system and software design to verification and production.
ASPICE (Automotive SPICE) is a process capability framework. OEMs use it to assess how their suppliers develop systems and software, and its assessments lean heavily on one thing: bidirectional traceability. Requirements trace forward to architecture, implementation, and tests; test results trace back to the requirements they verify. An assessor does not just ask whether the work products exist. They ask whether the links between them are consistent and current.
That is the common denominator. Neither framework is satisfied by artifacts alone. Both audit the chain. And the chain is exactly what most engineering toolchains do not store.
The evidence chain crosses every tool boundary in the organization. Hazard analysis lives in one tool. Safety requirements live in an ALM system. System design sits in PLM and CAD. Software versions live in their own repositories. Test results live with the test benches. Field data lives somewhere else entirely.
Each system keeps its own records, and most keep them well. What no system owns is the relationship between them: which test verified which requirement, in which software version, on which variant. Those links live in export spreadsheets, in traceability matrices assembled by hand, and in the memory of the engineers who did the work.
The result is that audit preparation becomes archaeology. The work was done; the tracing even happened. But proving it means reconstructing the chain after the fact, requirement by requirement, and repeating the exercise for every assessment, every variant, and every release. Variant complexity multiplies the cost: a requirement that is ASIL C on one configuration may not apply to another, and the evidence has to say so.
This is why compliance evidence keeps showing up as a line item measured in weeks of senior engineering time. Not because the organization is sloppy, but because the toolchain has no layer whose job is the links.
The structural fix is not another document repository. It is connecting the systems that already hold the artifacts, so the chain exists as data instead of as an annual reconstruction.
SPREAD's Engineering Intelligence Platform does this with an engineering ontology: a pre-built model of the relationships between requirements, parts, functions, software versions, tests, and traces, connected to PLM, CAD, ERP, ALM, MES, and simulation tools where the data already lives. Regulatory schemas extend the ontology as part of the customer's own subgraph, so the compliance structure of a specific program is modeled rather than bolted on.
The compliance consequence is direct. Every artifact, change, and decision is logged against the ontology, so compliance evidence is a byproduct of working, not a separate effort. Audit preparation collapses from a six-week sprint to a one-day evidence pull, with ISO 26262, DO-178C, EN 50128, and CMMC 2.0 included.
The same connected structure carries the day-to-day traceability work that feeds the evidence:
Explainability matters here too. Evidence a human cannot verify is not evidence, which is why AI operating on a structured product graph, where every answer cites the data behind it, is a different compliance proposition from AI bolted onto file archives. We unpack that principle in our guide to AI in systems engineering.
The hardest version of the compliance-data problem is not one program. It is one question crossing two certification regimes. At a post-merger automotive group (roughly $190B in group revenue, about 270,000 employees, fourteen marques across North America and Europe), the operative question is: is this brand-A body-control software certified for brand-B? Each legacy OEM brought its own homologation records and its own definition of what "certified" means for a given ECU class.
Answering that question used to be a multi-week reconciliation by senior engineers across two diverging toolchains. On one connected ontology, a single screen returns the certification deltas between the two legacy organizations' compliance records, the reuse precedents ranked by closeness of certification regime, and the open compliance gaps to close before a cross-brand deployment can ship.
Do not start with a compliance project. Start with the chain.
One honest boundary: connected data does not replace the process work. ASPICE assesses how your organization develops software, and no platform substitutes for doing that well. What connected data removes is the gap between doing the work and being able to prove it.
ISO 26262 compliance is the ability to demonstrate with evidence that a road vehicle's electrical and electronic systems meet the standard's functional safety requirements. That means hazards were analyzed, safety requirements were derived with the right ASIL classification, the requirements were implemented and verified, and the whole chain from hazard to test result is traceable.
ISO 26262 is a functional safety standard: it defines what a safe E/E system must demonstrate, including hazard analysis, ASIL classification, and a safety case supported by evidence. ASPICE is a process capability framework: it assesses how an organization develops systems and software, with bidirectional traceability between requirements, architecture, implementation, and tests as a core expectation. A program can need both: ASPICE for process capability, ISO 26262 for product safety.
Assessments expect a safety case: a structured argument that the system is acceptably safe, supported by evidence. In practice that means hazard analyses, safety requirements with ASIL classifications, design documentation, verification and test results, and, critically, the traceability links that connect them. Producing the individual artifacts is rarely the problem; producing the current, consistent links between them is where preparation time goes.
When engineering systems are connected through an ontology, every artifact, change, and decision is logged against one structure, so compliance evidence accumulates as a byproduct of normal work. Instead of reconstructing traceability matrices before each assessment, teams query the links that already exist. On SPREAD's platform, audit preparation collapses from a six-week sprint to a one-day evidence pull, with ISO 26262, DO-178C, EN 50128, and CMMC 2.0 included.
The assessment is not the expensive part. The archaeology is. Keep the links, and the evidence keeps itself.
See what an evidence pull looks like on your own systems. Get started with SPREAD.