If your software ends up in a vehicle, sooner or later a customer will ask about your Automotive SPICE capability level. For established electronics suppliers that question is routine. For software companies, AI developers and start-ups entering the automotive market, it often arrives as an unwelcome surprise in the middle of a sourcing decision.

Automotive SPICE is the process assessment model vehicle manufacturers use to judge whether a supplier’s development processes can be trusted. Version 4.0 in 2023 was the biggest overhaul in its history, adding hardware and machine learning engineering for the first time. Version 4.1, published by the VDA Quality Management Center in August 2026, refines that model. This Insight explains how Automotive SPICE works, what has changed, and how software and AI teams can prepare without burying agile delivery in paperwork.

The short version: Automotive SPICE 4.1 is the current version, and it is an evolution of 4.0 rather than a rewrite. It assesses development processes, not products, against capability levels from 0 to 5, and most vehicle manufacturers expect suppliers to reach Level 2 on the processes in scope. Machine learning now has its own process group. Formal assessments are carried out by intacs-certified assessors; the preparation, which is where most of the effort lies, can start long before one is booked.

What Is Automotive SPICE?

Automotive SPICE is an automotive adaptation of the international process assessment standards in the ISO/IEC 33000 series. It is published by the Quality Management Center of the German Association of the Automotive Industry (VDA QMC) and consists of a process reference model, which defines the processes and their outcomes, and a process assessment model, which sets out the base practices and information items an assessor will look for.

Its scope covers the engineering of systems that contain software, hardware and, since version 4.0, machine learning components. The core engineering processes follow the familiar V-model logic: system requirements, architecture, integration and verification at system level, mirrored by requirements, design, construction and verification at software level. Supporting processes cover quality assurance, configuration management, problem resolution and change management, alongside project management and the management of suppliers.

How capability levels work

Each process in scope is rated on a capability scale from Level 0 (incomplete) to Level 5 (innovating). Level 1 means the process achieves its purpose: requirements exist, the software is designed and tested, and the outcomes are there. Level 2 means the process is managed: work is planned, monitored and adjusted, responsibilities and resources are defined, and work products are reviewed and controlled. Level 3 means the organisation has a defined standard process that projects tailor and follow.

The jump from Level 1 to Level 2 catches many teams out. A team can build excellent software and still fall short of Level 2 if planning, monitoring and work product control are informal or invisible. Level 2 is the common requirement in vehicle manufacturer sourcing, with Level 3 increasingly requested for critical systems.

What Changed in Version 4.0

Version 4.0, released in late 2023, restructured the model around a plug-in concept, so that hardware, machine learning and validation processes can be added to an assessment scope as the product requires. It introduced a Hardware Engineering process group and a Machine Learning Engineering process group, together with a supporting process for machine learning data management. Work products were renamed information items, and traceability and consistency requirements were consolidated into the engineering base practices rather than scattered across the model.

For AI teams, the machine learning processes are the headline. They cover machine learning requirements, architecture, training and testing, while the data management process addresses how training and validation data is specified, collected, labelled, assured and controlled. For the first time, an assessor has a defined basis for asking how a model was trained and how its data was governed.

What Is New in Version 4.1

Version 4.1 is a refinement. A preview was published in April 2026 and the final model followed in August 2026 (VDA QMC Automotive SPICE publications). The changes clarify base practices and outcomes rather than altering how projects are assessed; for example, stakeholder identification is now explicit within system requirements elicitation. Alongside it, VDA QMC published a third edition of the Automotive SPICE Guidelines, which interpret the model for assessors and include new guidance on topics such as AI assistance in development.

For organisations already working to 4.0, the move to 4.1 should be modest. For organisations still working to version 3.1, the gap is significant, because the bigger structural changes came with 4.0. Customers may specify which version an assessment must use, so it is worth confirming that before planning.

Where Automotive SPICE Meets Other Requirements

Automotive SPICE rarely arrives alone. Functional safety under ISO 26262 and cybersecurity under ISO/SAE 21434, which supports the type-approval requirements of UNECE Regulation R155, both depend on disciplined development processes. A separate Automotive SPICE for Cybersecurity model extends the assessment to security engineering. For AI components, ISO/PAS 8800 addresses safety and artificial intelligence in road vehicles, and organisations governing AI more broadly may also look to ISO/IEC 42001.

The quality management system ties these together. The forthcoming IATF 16949 second edition names software quality assurance as one of its five priorities, which brings the core automotive quality standard closer to the development disciplines Automotive SPICE has long expected.

Where Software and AI Teams Struggle

Assuming agile and Automotive SPICE are incompatible

Automotive SPICE does not prescribe a lifecycle. It asks for outcomes and evidence, and agile teams can provide both. The problems arise when backlog items lack traceability to requirements, when definitions of done omit verification criteria, or when architectural decisions live only in conversations. The fix is usually configuration of existing tools, not a return to waterfall.

Retrofitting traceability

Bidirectional traceability between requirements, architecture, code and tests is central to the model. Teams that try to reconstruct it weeks before an assessment spend enormous effort and rarely convince an assessor. Traceability built into the workflow from the start costs far less and becomes a genuine engineering asset.

Treating Level 2 as paperwork

Level 2 is about managing work, not producing documents. Plans that nobody updates, reviews recorded after the fact and status reports disconnected from reality are all visible to an experienced assessor. The evidence that works is the evidence teams already use to run their projects.

Overlooking data management

Machine learning teams often have strong model training practices but informal data governance. Where datasets came from, how they were labelled and checked, and how versions are controlled are now assessable questions. Getting data management under control is often the largest single task for an AI team approaching its first assessment.

How Hillscom Helps

Hillscom does not carry out formal Automotive SPICE assessments, which are performed by intacs-certified assessors. Our role is preparation and improvement. We review your development processes against the model to identify gaps, help you define proportionate processes that fit agile delivery and your existing toolchain, and build traceability, review and configuration practices into the way your teams already work. Because Automotive SPICE sits alongside a quality management system, we also help connect it to ISO 9001, IATF 16949 and ISO 27001, so evidence serves more than one purpose.

This approach suits established suppliers preparing for reassessment against version 4.x, and particularly software and AI companies supplying the automotive industry for the first time. You can read more about our work in the automotive and technology sectors, or about our gap analysis and readiness service.

The Hillscom Perspective

The software and AI companies now entering automotive often move faster and engineer more creatively than the industry they are joining. What they sometimes lack is the habit of making their discipline visible. Automotive SPICE is, at heart, a structured way of asking a supplier to prove that good engineering is repeatable rather than heroic. Teams that treat it as a lens on their own practices, rather than an external checklist, tend to reach the required level faster and come out with better processes than they went in with.

Conclusion

Automotive SPICE 4.1 consolidates the major changes of version 4.0, including dedicated processes for machine learning and data management. For suppliers already working to 4.0 the step is small; for those still on 3.1, or new to the automotive market, preparation takes time. Start with traceability, managed planning and data governance built into existing tools, and the assessment becomes confirmation of good practice rather than a scramble.

If your organisation is preparing for an Automotive SPICE assessment or entering the automotive supply chain, Hillscom can provide a practical review of your development processes aligned to how your teams actually work. Get in touch for a free consultation.

Automotive SPICE® is a registered trademark of the Verband der Automobilindustrie e.V. (VDA).