ASPICE Under Pressure: How Automotive Suppliers Are Navigating the Level 2 Mandate
The conversation used to happen in program kickoff meetings, buried in a list of quality deliverables. Now it’s happening in supplier selection, before any statement of work is signed. If you supply safety-relevant software or systems to a tier-one automotive OEM — particularly a German one — and you cannot demonstrate ASPICE Capability Level 2, you are not getting the business. If you want to be a strategic partner, the target is Level 3.
Automotive SPICE, the automotive industry’s adaptation of ISO/IEC 33000-series process assessment models, has been a fixture of German OEM supplier requirements since the mid-2000s. Volkswagen Group, BMW Group, and Mercedes-Benz have required supplier assessments for years. What’s changed in the last three years is the scope, the stringency, and the consequences of falling short.
The mandate is now extending aggressively into electrification and ADAS supply chains — domains that previously operated with more engineering latitude. It is spreading to North American and Asian OEMs who are following the German lead on safety process rigor. And the threshold for “acceptable” has shifted upward. Level 1 — proof that a process is performed — is no longer sufficient for new business. Level 2, which requires that processes are managed, planned, monitored, and have defined work products, is the floor. Level 3 — where processes are defined, standardized, and consistently applied across the organization — is where OEMs want their critical partners.
Suppliers are responding. But the response is uneven, expensive, and in some cases, more about documentation than discipline.
What OEMs Are Actually Requiring
The specific requirements vary by OEM, but the pattern is consistent. A mid-size ADAS supplier working with multiple European OEMs will typically face:
- An initial self-assessment submission before supplier qualification, often using OEM-specific questionnaires aligned to ASPICE process areas
- An OEM-conducted or third-party-conducted assessment within 12–18 months of program start
- An improvement plan with defined milestones if assessment results fall below target
- Re-assessment requirements, typically every 2–3 years, sometimes tied to program renewals
The process areas under heaviest scrutiny are not surprising: SYS.1 (Requirements Elicitation), SYS.2 (System Requirements Analysis), SYS.3 (System Architectural Design), SWE.1 (Software Requirements Analysis), SWE.2 (Software Architectural Design), and the verification and validation processes SYS.4, SYS.5, SWE.4, SWE.5, SWE.6. For ADAS and electrification suppliers, the intersection of ASPICE with ISO 26262 functional safety requirements adds another layer, because assessors are increasingly evaluating whether process compliance supports — or undermines — safety case integrity.
One consequence of this multi-OEM reality: a supplier working with three different OEMs may face three different assessment schedules, using three interpretations of the same standard. The standard itself is harmonized. The implementation of requirements is not.
The Cost Suppliers Aren’t Talking About Publicly
Supplier executives will discuss ASPICE improvement programs in general terms. They are less forthcoming about what those programs actually cost. Based on conversations with process improvement consultants, quality directors at tier-one and tier-two suppliers, and ASPICE certified assessors, the economics look something like this:
A credible improvement program for a supplier starting from a baseline of informal, undocumented processes — which describes many smaller engineering-focused companies — requires three categories of investment before a single formal assessment.
People. An ASPICE improvement program needs internal ownership. At minimum, a process quality lead with either ASPICE Provisional Assessor certification or direct experience. At realistic scale, a small process quality function. In a market where automotive software engineers are expensive, this is not a trivial cost. Organizations that try to delegate this to existing project managers without dedicated capacity consistently underperform.
Consulting. Most suppliers engage external ASPICE consultants for gap analysis, process definition, and pre-assessment coaching. Consulting engagements for a mid-size supplier (200–800 software engineers) run $200K–$600K over 12–24 months. The market for credible ASPICE consultants is tight, and rates have increased.
Tooling. This is where the costs become less visible but matter more than they used to. Assessors evaluating Capability Level 2 need to see that work products exist, are controlled, have defined attributes, and are traceable to each other. Document-based processes — requirements in Word, test cases in Excel, change requests in email — cannot demonstrate these properties at scale without heroic manual effort. The tooling investment required to move from document-based to connected, traceable processes is a significant capital and change management cost.
Total cost for an 18–36 month improvement program, including internal staffing, consulting, tooling, and assessment fees, runs $500K–$2M for a mid-size supplier. For small suppliers — under 100 software engineers — the per-capita cost is even higher, and the organizational disruption is proportionally greater.
Where Small and Mid-Size Suppliers Are Struggling
The suppliers under the most pressure are not the large tier-ones with established quality functions. Continental, Bosch, ZF, and Aptiv have invested in ASPICE infrastructure for years. Their challenge is sustaining Level 3 across a sprawling global organization as scope expands.
The acute pain is at the tier-two and tier-three level. These are engineering companies — often founded by domain experts in power electronics, sensor fusion, or embedded control — that built reputations on technical capability, not process rigor. They are now being told that technical excellence is necessary but not sufficient. Without demonstrated process maturity, they cannot access the supply chain relationships that would let them scale.
Several dynamics make this particularly difficult for smaller suppliers:
Overhead burden. An ASPICE-compliant process framework imposes real overhead on engineering work. Requirements must be formally elicited, analyzed, and documented with defined attributes. Changes must go through controlled change management. Verification activities must be planned, executed, and their results linked to requirements. For a 30-person engineering team, this overhead is not invisible. It changes how work gets done, and it has to be led from the top for adoption to happen.
Assessment as adversarial. Some suppliers describe OEM-led assessments as adversarial rather than developmental. Assessors arrive with limited context, run structured interviews, review artifacts, and produce findings. Improvement plans are generated. But the follow-through on supplier development — coaching, co-investment, support — is inconsistent. The result is that some suppliers are optimizing for assessment performance rather than actual process improvement.
Talent availability. Process quality talent with ASPICE expertise is concentrated in automotive hubs — Stuttgart, Munich, Munich, Detroit, Nagoya. Suppliers in other geographies face recruiting challenges on top of everything else.
One quality director at a 150-person embedded software supplier in the UK described the situation plainly: “We’ve spent 18 months and probably £400K getting to a point where we think we can pass a Level 2 assessment. I can show you the processes. What I can’t always show you is that the engineers actually use them consistently. That’s the gap. And the assessment doesn’t really distinguish between those two things.”
Tooling and the Traceability Problem
If there is a single technical theme running through current ASPICE improvement programs, it is traceability. Capability Level 2 requires that work products are controlled and traceable. Capability Level 3 requires that processes are defined and that work products conform to process definitions. Both levels, when assessed rigorously, expose the fundamental weakness of document-based toolchains: you can produce documents that look compliant without having processes that are actually connected.
Assessors — particularly those working under OEM contracts with recent calibration — are increasingly examining artifact consistency, not just artifact existence. If your System Requirements Analysis process claims that all system requirements are linked to stakeholder requirements, they will check a sample. If your Software Verification process claims that test cases are linked to software requirements and that test results are linked to test cases, they will check. Disconnected tool landscapes — requirements in one system, tests in another, change requests in a third, with no automated linkage — make this demonstration labor-intensive at best and impossible at scale.
The tooling market has responded. Traditional ASPICE-adjacent tools like IBM DOORS and DOORS Next, Jama Connect, and Polarion have long been positioned around requirements management with some traceability capability. These tools are deeply embedded in the supply chain. They are also, for many users, heavy to administer, expensive to license, and limited in the depth of cross-artifact intelligence they provide. They track links. They don’t analyze them.
Newer platforms are emerging that approach the problem differently. Flow Engineering, for example, builds requirements management around a graph-based model rather than a document hierarchy, meaning that traceability relationships are structural — part of how the system represents requirements and their connections — rather than bolted on as a linking feature. In ASPICE improvement programs specifically, this matters because the work product attributes that assessors evaluate — coverage, consistency, change impact — are properties of a connected model, not properties of linked documents. Whether a smaller supplier can justify the migration cost from their existing toolchain to a newer platform is a separate question, and it depends on where they are in their program lifecycle.
The honest assessment of tooling in ASPICE compliance work is this: the right tool will not make a bad process pass an assessment. But the wrong tool — or no tool — will make a good process fail one, because you cannot demonstrate what you cannot surface.
Is ASPICE Actually Improving Engineering Quality?
This is the question that automotive industry veterans are increasingly willing to ask aloud, and the answers are mixed.
The case for ASPICE as a quality driver is genuine. Organizations that invest seriously in requirements discipline, architectural design documentation, and verification planning consistently produce more predictable software. The processes that ASPICE assesses — when they are actually practiced, not performed for assessment — reduce late-cycle defect discovery, improve change impact analysis, and create the audit trails that matter when something goes wrong in the field. For ADAS and safety-critical electrification systems, this discipline is not optional.
The case for ASPICE as compliance theater is also real. Suppliers who have gone through assessment cycles describe the preparation ritual: gathering artifacts, updating documentation that has drifted from practice, coaching engineers on how to answer interview questions, ensuring that the right work products are findable. One principal engineer at a tier-one supplier was blunt: “Six weeks before the assessment, we have an all-hands on ASPICE. The rest of the year, we ship software.”
The structural problem is that ASPICE assessments are periodic, resource-intensive events conducted by people with limited program context. They assess evidence of process, not quality of outcomes. A supplier who manages requirements poorly but documents that poor management consistently can score better than a supplier with strong engineering instincts and incomplete documentation. This is a known failure mode of process assessment frameworks, not unique to ASPICE — but it is one that the automotive supply chain has not solved.
OEMs have leverage here that most are not using. Assessment results create a structured picture of supplier process capability over time. That picture could be used for targeted supplier development investment — supporting smaller suppliers in building genuine capability in exchange for long-term commitment. In practice, assessment results are more often used as qualification filters than as development tools. The supplier either meets the threshold or faces consequences. The nuance between “has the process but applies it inconsistently” and “lacks the process entirely” is often lost.
The Path Forward for Suppliers
The suppliers who are navigating this well share a few characteristics. They started the tooling and process work before the OEM mandate became acute, which means they are demonstrating capability rather than cramming for it. They have executive sponsorship that connects process quality to business risk, not just to compliance cost. And they are investing in traceability infrastructure — connected systems that make process compliance visible continuously, not just at assessment time.
For suppliers who are starting from behind, the realistic timeline is 24–36 months to a defensible Level 2 assessment result, assuming genuine investment. The suppliers trying to compress this into 12 months with consulting support and document-intensive preparation are producing assessment results, not process maturity.
The OEM community has an obligation here too. If Level 2 is genuinely the floor for safety-relevant software supply, then OEMs need to decide whether they are willing to invest in supplier development for partners with strong technical capability and developing process maturity, or whether they are willing to accept supply chain consolidation toward the larger tier-ones who can afford compliance at scale. Both are coherent strategies. Requiring Level 2 from everyone while providing development support to no one is not.
ASPICE, at its core, is a reasonable framework for asking whether engineering processes are managed, consistent, and capable of producing predictable outcomes. The automotive industry’s problem is not the framework. It is the gap between the discipline the framework describes and the compliance performance it often measures.