ASPICE Capability Levels and the New Reality of Automotive Software Quality
ASPICE capability levels are no longer an internal benchmark that only software engineers discuss. As vehicles become increasingly software-defined and OEMs tighten their supplier qualification criteria, understanding where your organisation stands on this maturity scale has become a commercial imperative — not a technical footnote.
If your company develops embedded software, electronic control units, or safety-critical systems for the automotive supply chain, the question is not whether this framework applies to you. The question is which level your customers are already requiring — and whether you are ready to demonstrate it.
What Is ASPICE and Why Does It Matter
Automotive SPICE — formally known as Automotive Software Process Improvement and Capability dEtermination — is the internationally recognised framework for assessing the maturity of software development processes in the automotive industry. Developed under VDA Quality Management Center governance and aligned with ISO/IEC 15504, it provides OEMs and Tier 1 suppliers with a structured, objective method for evaluating the process capability of their suppliers across the full software development lifecycle.
The standard is increasingly widespread across the automotive industry, with many OEMs and their multi-tier networks requiring all their suppliers to demonstrate at least Level 2, with plans to achieve Level 3 for future projects.
The framework is not legally mandatory. But in practice, compliance has become a de facto requirement for doing business with major OEMs. Leading automotive companies including Volkswagen, BMW, Daimler, Ford and others require their suppliers to demonstrate specified capability levels as a condition for contract awards.
That distinction — between legally required and commercially essential — is one that automotive suppliers have learned the hard way.
The Six Capability Levels: A Clear Map
The standard defines six levels of process maturity, from CL0 to CL5. Each level builds on the previous one, demanding greater structure, consistency, and evidence of process control.
CL0 — Incomplete
The process is not implemented or consistently fails to achieve its intended purpose. No systematic approach exists. At this level, an organisation has no credible basis for claiming software quality assurance.
CL1 — Performed
The process achieves its purpose — software gets delivered — but outcomes depend on individual effort rather than defined practices. Results are produced but consistency is not guaranteed. There is no reliable way to predict or repeat success.
CL2 — Managed
The process is planned, tracked and documented. Work products are defined and traceability between requirements and outputs is established. This is the minimum level most OEMs require from Tier 1 suppliers. Achieving this level means your organisation can demonstrate control: you know what you are building, why you are building it, and how the output links back to requirements. Today, major global OEMs have made it standard to require CL2 or above in their Statement of Work and Request for Information documents.
CL3 — Established
Standard processes are defined at the organisational level and tailored per project. Process improvement is systematic and continuous rather than reactive. This level is increasingly expected for safety-related software. It moves beyond the Managed tier to Established, reflecting a level of maturity where processes are well-defined, standardised and actively managed. For organisations developing ADAS systems, functional safety software, or any component subject to ISO 26262, CL3 is becoming the threshold, not the aspiration.
CL4 — Predictable
Process performance is quantitatively measured and outcomes are statistically predictable. This level requires significant investment in measurement infrastructure and is rarely demanded by OEMs as a blanket requirement.
CL5 — Innovating
Continuous process innovation is embedded in the organisation. Performance targets are proactively optimised. In practice, CL4 and CL5 are theoretically defined but rarely required as contractual obligations.
Why CL2 and CL3 Are the Practical Focus
The gap between CL1 and CL2 is often larger than organisations expect. Moving from delivering software to demonstrating managed, traceable, documented processes requires a structural shift — in how projects are planned, how requirements are managed, how work products are defined, and how evidence is collected and maintained throughout the development cycle.
The gap between CL2 and CL3 is a different kind of challenge. It is not just about doing more — it is about doing things the same way, consistently, across the organisation. Processes must be defined at the corporate level, not just applied project by project. For companies with multiple development teams, achieving CL3 requires genuine organisational alignment, not just process documentation.
Both transitions demand time. For new projects, a realistic roadmap to CL2 spans approximately twelve months. For existing projects requiring reverse-engineering of process compliance, eighteen to twenty-four months is a more realistic timeline. Organisations that treat this as a last-minute audit preparation exercise invariably discover this too late.
Version 4.0: What Has Changed
The most recent version of the framework, released in November 2023, introduced significant structural changes relevant to any organisation developing automotive software today.
The update added Hardware Engineering processes — HWE.1 through HWE.4 — bringing hardware development formally within the scope for the first time. It also introduced Machine Learning Engineering processes — MLE.1 through MLE.4 — reflecting the growing role of AI-driven components in modern vehicles, from perception systems in autonomous driving to predictive maintenance functions.
Cybersecurity alignment was also strengthened, with version 4.0 designed to work in closer conjunction with ISO/SAE 21434 and the requirements of UN R155. The transition period from the previous version ended in the first quarter of 2025 and OEMs are increasingly demanding evidence of compliance with the updated standard.
For organisations still operating under the previous version, the question is no longer whether to transition — it is how to do so without disrupting active development programmes.
Where Ariol Automotive Comes In
At Ariol Automotive, we work with software suppliers, Tier 1 and Tier 2 companies, and OEM development teams at every stage of this journey. From initial gap analysis against CL2 requirements, through process design and implementation, to preparation for formal assessment by an intacs-certified assessor.
Our approach is practical and project-grounded. We do not deliver generic process frameworks that sit on a shelf. We work alongside development teams to build compliant processes that fit the way your organisation actually works — and that hold up under independent assessment.
Whether your organisation is approaching its first CL2 assessment, planning a transition from CL2 to CL3, or navigating the migration to version 4.0, Ariol Automotive has the expertise to guide that process efficiently and with a clear commercial objective in mind: getting you to the level your customers require, and keeping you there.
Ready to understand where your organisation stands? Contact the Ariol Automotive team to request an ASPICE gap assessment.
