Automotive SPICE (ASPICE) 4.0: A Complete Guide

A Tier 1 supplier walks into an Automotive SPICE (ASPICE) assessment with strong individual projects, only to lose points because it can’t demonstrate a documented company-level process with tailoring records. That gap costs weeks of remediation and puts the next sourcing program at risk. 

The volume of embedded software shipped in vehicles keeps climbing faster than most teams can scale their processes to match, and software-heavy systems like infotainment continue to account for new-vehicle quality concerns. Original Equipment Manufacturers (OEMs) are responding by requiring suppliers to demonstrate that their development processes can produce reliable software at scale, and ASPICE is the framework they use to assess this capability. ASPICE 4.0 expands the assessment scope beyond software to broader system coverage and changes the process structure, capability guidance, and assessment preparation priorities. 

This guide covers what ASPICE is, what changed in version 4.0, how capability levels and assessments work, and how to prepare your team.

What Is Automotive SPICE (ASPICE)?

ASPICE evaluates the capability of development processes for embedded automotive systems through its Process Assessment Model (PAM). Working Group 13 (WG13) of the Quality Management Center (QMC) within the German Association of the Automotive Industry (VDA) governs it. Automotive SPICE combines a Process Reference Model (PRM) and a PAM in a single document.

Why OEMs Use ASPICE to Qualify Suppliers

OEMs use ASPICE to evaluate and qualify suppliers. Because manufacturers can’t individually verify every piece of software delivered across their supply chains, they evaluate the quality of the development process itself. Suppliers receive per-process capability level ratings from Intacs-certified assessors, and those ratings determine whether they remain competitive for sourcing programs.

Why There Is No Single “ASPICE Certified” Score

ASPICE assigns an independent capability level rating to each assessed process. Companies do not receive “ASPICE certified” status. A consolidated score for a project or company doesn’t exist, and that specificity is by design. It makes findings actionable at the process level, where teams can address them.

How ASPICE Connects to the ISO/IEC 33000 Series

ASPICE develops its PAM in accordance with the International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC) 33004:2015, which defines requirements for process reference and assessment models. ASPICE 4.0 defines its own measurement framework as an adaptation of ISO/IEC 33020:2019, an update from PAM 3.1’s reference to the 2015 edition.

Why ASPICE Matters for Automotive Software Quality

Advanced Driver Assistance Systems (ADAS) and autonomous driving software are growing rapidly, and software integration, verification, and validation services are expanding as well. As vehicles take on more software-driven functions, development teams must manage a growing number of requirements, interfaces, and potential failure modes.

Assessor certifications under the Intacs scheme are recognized worldwide across the automotive industry, and the framework is now used across more than 50 countries. OEMs often require suppliers to demonstrate defined ASPICE capability targets. Some OEM-specific frameworks also require alignment with ASPICE alongside functional safety and cybersecurity expectations.

During design and development phases, ISO 26262 functional safety requirements and ASPICE overlap in meaningful ways. Teams that develop according to ASPICE may already satisfy multiple process-related requirements from ISO 26262, particularly in Part 8, supporting processes. ISO 26262 also includes a Quality Management (QM) classification for cases where the assessed risks are tolerable and no functional safety requirements are assigned.

What Changed in ASPICE 4.0

ASPICE 4.0 introduces structural changes from version 3.1 that affect process scope, capability scoring, and assessment preparation, as reflected in the official VDA ASPICE 4.0 publications.

How the Process Reference Model Was Consolidated

ASPICE 4.0 removes seldom-used processes, adds new processes and process groups, and reduces base practices compared with version 3.1, with the largest reductions in the System Engineering (SYS) and Software Engineering (SWE) groups, including SYS.3, SYS.4, SWE.2, and SWE.3.

What Changed When “Test” Became “Verification”

The shift from “test” to “verification” runs through the SYS and SWE groups:

• SYS.4: Renamed System Integration and Integration Test.
• SYS.5: Renamed System Verification.
• SWE.5: Renamed Software Component Verification and Integration Verification.
• SWE.6: Previously named Software Qualification Test.

Why Machine Learning and Cybersecurity Now Have Their Own Processes

The Machine Learning Engineering (MLE) process group adds processes for machine learning requirements analysis, architecture, training, and model testing. Cybersecurity engineering is addressed by the ISO and SAE International (ISO/SAE) 21434 standard, alongside a separate Automotive SPICE for Cybersecurity PAM. Suppliers can’t pursue a cybersecurity assessment without first having an Automotive SPICE assessment result covering the recommended VDA scope, including at least the system and software process groups.

How the Terminology Got Simpler in 4.0

“Output Work Products” became “Information Items” (II), and “Work Product Characteristics” became “Information Item Characteristics” (IIC). The name now reflects the framework’s expanded reach beyond software into broader system development. Previously separate traceability and consistency base practices were merged into a single base practice across all engineering processes.

How the ASPICE 4.0 Process Reference Model Is Organized

The PRM organizes core processes into Primary Lifecycle, Supporting Lifecycle, and Organizational Lifecycle categories.

How the V-Model Shapes the Engineering Processes

The SYS group follows a V-model structure from requirements elicitation (SYS.1) through system verification (SYS.5), where each left-side process pairs with its right-side verification process. SWE mirrors this at the software level, from software requirements analysis (SWE.1) through software verification (SWE.6).

What’s New: Validation and Hardware Engineering

VAL.1 Validation is a new single-process group in ASPICE 4.0. The Hardware Engineering (HWE) group adds processes covering electrical and electronic hardware requirements, design, and verification, while excluding several areas outside that scope.

Which Supporting and Management Processes You’ll Be Assessed On

Supporting processes include Quality Assurance (SUP.1), Configuration Management (SUP.8), Problem Resolution Management (SUP.9), Change Request Management (SUP.10), and Machine Learning Data Management (SUP.11, new in 4.0). Management processes are Project Management (MAN.3), Risk Management (MAN.5), and Measurement (MAN.6).

How ASPICE Capability Levels and Scoring Work

Each assessed process receives an independent capability level rating on a scale from 0 to 5. The VDA ASPICE Guideline scopes its guidance to the lower capability levels because this range covers most automotive assessments.

What Each of the Six Capability Levels Means

Each level builds on the previous one:

• Level 0 (Incomplete): The process fails to achieve its purpose.
• Level 1 (Performed): The process achieves its purpose.
• Level 2 (Managed): Planning, monitoring, and controlled work products are in place.
• Level 3 (Established): A defined company-level process exists with project-level tailoring.
• Level 4 (Predictable): The process operates within defined limits using measurement data, with corrective action taken on assignable causes of variation.
• Level 5 (Innovating): Continuous improvement is institutionalized.

How Assessors Score Each Process Attribute

Process attributes are evaluated using the Not achieved, Partially achieved, Largely achieved, Fully achieved (NPLF) scale. Not achieved covers 0 to 15 percent, Partially achieved covers more than 15 to 50 percent, Largely achieved covers more than 50 to 85 percent, and Fully achieved covers more than 85 to 100 percent. Achieving a given capability level requires all lower-level attributes to be fully achieved and the target level’s own attributes to be at least largely achieved.

Assessors evaluate Base Practices and Information Items at Level 1, while Generic Practices and Generic Information Items are capability indicators at Level 2 and above. Only intacs-certified assessors can conduct VDA-recognized assessments.

How ASPICE Relates to Other Automotive Standards

ASPICE, ISO 26262, ISO/SAE 21434, and IATF 16949 address different dimensions of automotive quality, and teams often map them together through compliance matrices.

How ASPICE and ISO 26262 Functional Safety Fit Together

ASPICE measures process capability, while ISO 26262 specifies functional safety requirements, with Automotive Safety Integrity Level (ASIL) risk classification used in automotive applications. Configuration management (SUP.8) and change management (SUP.10) requirements are closely aligned across both standards. ASPICE Capability Level 2 (CL2) conformance does not imply ISO 26262 ASIL compliance, and vice versa.

Where ASPICE and ISO/SAE 21434 Cybersecurity Overlap

The ASPICE for Cybersecurity PAM and ISO/SAE 21434 address automotive cybersecurity from different perspectives. ASPICE can provide a useful structure for implementing and assessing some of ISO/SAE 21434’s process-related expectations, and the United Nations Economic Commission for Europe (UNECE) regulation R155 gives OEMs a regulatory reason to require automotive cybersecurity process evidence from suppliers.

How IATF 16949 Quality Management Connects to ASPICE

IATF 16949 automotive quality management has been discussed alongside ASPICE for embedded software development. There is meaningful overlap between the VDA-recommended assessment scope and IATF 16949 requirements, giving companies already certified to IATF 16949 a head start on ASPICE implementation.

How to Implement ASPICE 4.0 in Your Development Process

The transition from 3.1 to 4.0 affects every process in scope. Teams beginning implementation should start with the VDA QMC’s freely available PAM 4.0 document and the ASPICE Guideline v2.1.

Where Should You Start a 4.0 Gap Analysis?

An early gap analysis identifies strengths and weaknesses before teams invest in a full assessment. HWE and MLE process groups require new process definitions built from scratch. Transition guidance is split here. Some guides advise defining new processes from scratch when areas such as HWE and MLE apply, while others emphasize translating existing 3.1 processes into the 4.0 structure where possible.

How to Prove Traceability and Consistency Together

ASPICE 4.0’s merged traceability-and-consistency base practice requires teams to demonstrate bidirectional traceability across the V-model and alignment between linked artifacts. VDA guidance distinguishes requirements traceability from consistency, so traceability alone does not guarantee that linked information is consistent. Acceptable mechanisms for demonstrating consistency include peer spot checks, pair review, and annotations. A requirements and traceability platform helps teams maintain trace links from system requirements through verification results while tracking changes that affect downstream artifacts.

How to Prepare Before a Formal Assessment

Teams should conduct internal pre-assessments against the Potential Analysis PAM before formal assessment activities. The expansion to hardware and machine learning process groups means teams previously assessed only on software now face new process design work with no 3.1 precedent. Teams that rely on tool-generated trace matrices without systematic semantic review will need to add consistency evidence practices before their next assessment.

Where Teams Struggle Most With ASPICE Compliance

Compliance gaps tend to cluster around traceability, change management, and process definition rather than the engineering work itself.

Why Traceability Breaks Down Across Distributed Teams

Traceability chains break across company boundaries when work products live in different tools and repositories. ACQ.4 (Supplier Management) and SPL.2 define process obligations at these interfaces, but teams must establish explicit agreements on how links are maintained across tool boundaries.

How Change at Scale Creates Traceability Debt

Every level of the V-model has an explicit traceability-based practice. When changes occur without consistent downstream impact analysis, traceability debt accumulates. SUP.10 requires change requests linked to artifacts to be analyzed before the change proceeds.

What It Takes to Demonstrate Consistency Between Process Levels

Reaching Level 3 requires evidence of a defined company-level process that is consistently tailored for individual projects. Teams that perform well on individual projects but can’t demonstrate a documented standard process, including tailoring records and cross-project performance data, will face findings during assessment.

How Jama Connect® Supports ASPICE 4.0

Teams preparing for ASPICE 4.0 assessments need a reliable way to keep links current across requirements, verification artifacts, change records, and downstream evidence. Jama Connect is a requirements and traceability platform with a built-in framework mapping to the ASPICE 4.0 Process Assessment Model, so automotive teams start from the structure assessors expect.

Live Traceability™ keeps upstream and downstream connections up to date across development artifacts and flags downstream items as suspect when an upstream requirement changes. That same workspace supports teams that need to satisfy both ASPICE and functional safety expectations, rather than reconciling evidence across disconnected tools.

Getting Your Team Ready for ASPICE 4.0 Assessments

ASPICE 4.0 rewards teams that treat documented process intent and connected evidence as outputs of everyday work, not as a scramble that starts when an assessment is scheduled. As automotive systems expand beyond software into hardware and machine learning, that habit is what separates a clean assessment from weeks of remediation. If your team is still assembling that evidence by hand before each assessment, you can keep the picture connected as you work and start a free 30-day trial to see how it holds up.

Frequently Asked Questions About ASPICE 4.0

What is the difference between ASPICE and ISO 26262?

ASPICE evaluates whether development processes are capable and repeatable. ISO 26262 specifies what functional safety activities and artifacts a project must produce based on risk classification (ASIL A through D). Achieving ASPICE Level 2 doesn’t imply ISO 26262 compliance, and meeting ISO 26262 requirements doesn’t guarantee any particular ASPICE capability level.

Is ASPICE mandatory for automotive suppliers?

No law or regulation mandates ASPICE compliance. OEMs often impose ASPICE as a contractual requirement on Tier 1 and Tier 2 suppliers. Suppliers who can’t demonstrate the capability level specified in their OEM supply agreement risk disqualification from sourcing programs, which makes it necessary for most automotive supply chain positions.

What are the ASPICE capability levels?

There are six levels, rated per individual process, from Level 0 (Incomplete) through Level 5 (Innovating). Assessors rate each process independently using the NPLF scale across process attributes, and each level requires that all lower-level attributes be fully achieved before the target-level attributes are evaluated.

How does ASPICE 4.0 differ from version 3.1?

The scope expanded from software to broader system coverage, adding Hardware Engineering, Machine Learning Engineering, and Validation process groups. Roughly ten processes were removed and ten added, and the measurement framework and Level 3 guidance were reworked. Adoption of the 4.0 model is now underway across the industry.