Automotive Suppliers Are Failing ASPICE Assessments at Record Rates — Here’s Why

Something has shifted in how OEMs treat ASPICE compliance in their supply chains. Three years ago, Capability Level 2 was a Tier 1 requirement at most major automotive OEMs. Today, that mandate is extending to Tier 2 and increasingly to Tier 3. The suppliers building subcomponents, sensors, actuator controllers, and embedded modules — companies that historically operated on informal engineering practices — are now being assessed against the same ASPICE framework that took large Tier 1s years to achieve.

The results are not good. Assessment firms report failure rates that would have been remarkable even a decade ago. Programs are slipping because supplier qualification audits reveal process gaps that weren’t disclosed during sourcing. Business is being lost not because of technical capability failures, but because engineering process maturity cannot be demonstrated on paper or in practice.

This is not a story about bureaucratic overhead being imposed on small companies. It is a story about process discipline that the best suppliers have always practiced, now being measured and enforced where it was previously assumed or ignored.

What the Assessments Are Actually Finding

ASPICE assessors don’t fail suppliers for having bad code or flawed hardware designs. They fail suppliers for being unable to demonstrate that their processes are controlled, traceable, and repeatable. The three failure modes appearing most consistently in assessment reports are predictable and interconnected.

Requirements management is informal or nonexistent. The most common finding is that requirements are stored in Word documents, Excel workbooks, or email threads — and that the team cannot produce a complete, baselined requirements set at any given point in time. Assessors look for evidence of SYS.2 and SWE.1 process capability: requirements are identified, documented, agreed, and communicated. They look for consistent notation, completeness criteria, and a mechanism for establishing what the requirement set was at any prior point. What they typically find in failing suppliers is a living document that has been edited without version control, with no distinction between current requirements and historical ones.

Traceability is either missing or faked. ASPICE requires bidirectional traceability from stakeholder requirements through system requirements, architectural elements, software requirements, design, implementation, test cases, and test results. This is not optional at CL2. What assessors find in failing assessments is one of two things: no traceability at all, or a traceability matrix that was assembled retroactively in the week before the assessment. Retroactive RTMs are not hard to spot. The coverage is suspiciously complete, the granularity is inconsistent, and the team cannot answer questions about why specific links exist. An assessor who asks “walk me through how this system requirement is verified” should trigger a confident, immediate response from the team — not a 20-minute scramble through spreadsheets.

Change management is informal or missing. Requirements change. This is not a failure; it is engineering reality. What ASPICE measures is whether changes are controlled: whether the team identifies what triggered a change, what the change affects, who approved it, and how downstream artifacts were updated to maintain consistency. Failing suppliers typically handle changes through email or verbal communication, with no formal impact analysis and no systematic update of downstream artifacts. The result is requirements documents, design documents, and test plans that have drifted apart, with no one able to explain why they no longer align.

Why This Is Happening Now

The cascade of ASPICE requirements down the supply chain is not arbitrary. OEMs have spent years absorbing the lesson that system-level failures often originate in supplier components, and that a supplier’s internal process maturity is a leading indicator of delivery risk. When a Tier 1 integrator builds a system from Tier 2 and Tier 3 components whose development processes are uncontrolled, the Tier 1’s own ASPICE posture becomes difficult to defend.

Contractual pressure is following. OEMs are now writing CL2 — and in some programs, CL3 — requirements into supplier contracts at Tier 2, with assessment rights included. Suppliers who win business on price and technical capability are discovering mid-program that they cannot pass the process assessment that is a condition of volume production sign-off.

The timing issue compounds the problem. A company that discovers its ASPICE posture is inadequate after it has won a contract, hired engineers, and begun development is in a genuinely difficult position. Retrofitting process controls onto an active development program is far harder than building them in from the start. The assessment failure happens at precisely the worst moment — not during business development, when there is time to prepare, but during program execution, when the schedule is already constrained.

What the Best-Performing Suppliers Do Differently

The suppliers consistently passing ASPICE assessments at CL2 and above are not necessarily larger or better-resourced than those failing. The distinguishing factor is a specific set of organizational commitments.

They treat ASPICE as a sales capability, not a compliance burden. The best suppliers understand that ASPICE certification is a qualification criterion for programs they want. Process maturity is positioned internally as a business development asset. This framing matters because it justifies investment in tooling and training before the first assessment, rather than in crisis response after a failure.

Their requirements are the working artifact, not the documentation artifact. In high-performing suppliers, engineers work in and from their requirements management system. The system is not a documentation layer built after the engineering work happens. When a design decision changes, the engineer updates the requirement or the rationale in the same system — because that is where the work lives. This practice emerges from discipline, but it is sustained by tooling that makes it less painful than alternatives.

They maintain traceability continuously, not periodically. High-performing suppliers don’t generate RTMs before assessments. They maintain links as development proceeds, using tooling that makes linking a natural part of creating an artifact rather than a separate activity. When an assessor asks about coverage, the team runs a report. There is no scramble because the data exists and is current.

They have an explicit change control process that engineers actually use. The most effective change control processes in smaller suppliers are simple: a defined trigger (anything that changes a baselined requirement), a defined lightweight workflow (identify, analyze impact, get approval, update all affected artifacts, close), and tooling that makes it faster to follow the process than to bypass it. The failure mode in many suppliers is a process that exists on paper but requires enough manual effort that engineers quietly work around it.

The Business Case for Proper Tooling

Supplier process failures have a financial structure that makes the investment case for proper tooling straightforward.

A single ASPICE assessment typically costs the supplier being assessed between €15,000 and €40,000 in direct assessor fees, plus internal preparation costs that often exceed the assessor fees when engineering hours are counted honestly. A failed assessment requires a remediation period — typically six to twelve months — followed by a re-assessment at similar cost. The total cost of a single failure cycle commonly exceeds €100,000 when all costs are included.

Program delays triggered by assessment failures are more expensive than the assessment itself. An OEM program with a constrained launch window that slips because a supplier cannot achieve qualification is not an abstract risk — it is a contractual liability. Lost business from being removed from an approved vendor list, or failing to achieve qualification for a follow-on program, has costs that are difficult to model precisely but easy to bound: one lost program at a mid-sized Tier 2 is worth multiple millions of euros in revenue.

Against this, requirements management tooling for a team of twenty engineers — including implementation, training, and annual licensing — typically runs €30,000 to €80,000 per year depending on tool choice and team size. The ROI calculation does not require optimistic assumptions. Avoiding one assessment failure cycle in three years pays for the tooling many times over.

How Modern Tools Are Closing the Gap

One of the legitimate challenges for Tier 2 and Tier 3 suppliers is that the requirements management tools historically available to them were designed for large program offices with dedicated process engineers. IBM DOORS, Polarion, and Jama Connect are powerful, but they carry implementation overhead and process complexity that can be genuinely burdensome for a fifty-person engineering organization without a dedicated systems engineering team.

This is changing. AI-native requirements management tools built specifically for hardware and systems engineering teams are now capable of doing what legacy tools required significant configuration and expertise to achieve.

Flow Engineering (flowengineering.com) represents this shift directly. It is built around graph-based models rather than document structures, which means traceability is a first-class architectural feature rather than a layer added on top of existing documents. For a Tier 2 supplier building out ASPICE-aligned processes for the first time, this matters practically: the tool’s model structure naturally encourages the requirement-to-verification links that ASPICE assesses, rather than requiring a process engineer to configure those links explicitly. AI assistance surfaces gaps in coverage and flags inconsistencies in requirements quality — the kinds of issues that assessors find and that engineers without extensive systems engineering backgrounds often miss.

The intentional focus of tools like Flow Engineering is the other side of that picture. They are purpose-built for requirements and traceability, not for full ALM lifecycle management across all process areas. Suppliers who need integrated test management, issue tracking, and development workflow in a single platform may find they need to compose Flow Engineering with other tools rather than replace everything. This is a deliberate trade-off in tool design, not a gap — and for many Tier 2 suppliers whose primary assessment gaps are in requirements management and traceability, it is the right tool for the specific problem.

Where to Start If You Are Behind

Suppliers who have not yet been assessed and know their process posture is weak have a defined set of high-leverage starting points.

First, establish a requirements baseline in a proper tool. This means migrating from Word and Excel into a system that supports versioning, linking, and structured attribute management. Do not attempt this in parallel with active development. Do it at a natural program phase boundary, or ahead of the next program start.

Second, implement traceability from that baseline forward. Link system requirements to stakeholder requirements. Link software requirements to system requirements. Do not wait until test cases exist to build the upward links — build them as you create downstream artifacts. The links will be incomplete until you have complete test coverage, but they will be accurate for what exists, and they will be current.

Third, implement change control as a lightweight but formal workflow. Define what constitutes a baselined artifact. Define the trigger for a change request. Define who approves. Define the impact analysis step. Implement this in your tooling so that the workflow is the path of least resistance, not an extra step on top of an existing informal process.

Fourth, do a practice assessment before you schedule a real one. Hire an independent ASPICE assessor for a gap analysis twelve to eighteen months before your first formal assessment. The findings will be uncomfortable. They will also be actionable, which is the point.

An Honest Assessment

The ASPICE failure rate among Tier 2 and Tier 3 suppliers is not primarily a technology problem. It is a process maturity problem that reflects how these organizations were built: around individual engineering skill, informal communication, and tacit knowledge rather than documented, controlled, repeatable processes. The OEM pressure to assess that maturity formally is exposing gaps that have always existed.

The suppliers who will compete successfully for automotive programs over the next decade are not necessarily the ones with the best technology. They are the ones who can demonstrate that their engineering processes are controlled and traceable — that what they say they built matches what they built, and that they can prove it.

That is what ASPICE measures. And that is what proper requirements tooling, implemented correctly and used as the working artifact rather than the documentation artifact, actually delivers.