Capability Levels 0–5 - ASPICE & Process

The Capability Level Framework

The Capability Level (CL) framework is ASPICE's quantified answer to the question: "How well is this process being performed?" It is a six-point ordinal scale from CL0 (Incomplete) to CL5 (Optimizing), and it applies per process, per project instance - not as an organization-wide rating.

The framework is defined in ISO/IEC 33020 (the measurement framework standard) and is used identically in ASPICE and any other ISO 33000-conformant process assessment model. The scale is ordinal and strictly cumulative: you cannot achieve CL2 for a process without first fully satisfying CL1. If a single Process Attribute at a lower level is not Largely Achieved, the higher level cannot be claimed.

📋 Learning Objectives

Name all six Capability Levels, their labels, and their corresponding Process Attributes
Explain exactly what Generic Practices GP 2.1.x and GP 2.2.x require with concrete examples
Apply the N/P/L/F rating to a real set of project evidence
Explain why CL2 requires more organizational investment than CL1, and CL3 requires more than CL2
Identify the most common reasons CL2 is failed in actual assessments

CL	Label	Process Attributes (PA) Required	Core Question
0	Incomplete	None (PA 1.1 not achieved)	"Is the process being performed at all?"
1	Performed	PA 1.1 Process Performance	"Does the process achieve its intended purpose?"
2	Managed	PA 1.1 + PA 2.1 (Performance Mgmt) + PA 2.2 (Work Product Mgmt)	"Is the process planned, tracked, and producing managed work products?"
3	Established	CL2 + PA 3.1 (Process Definition) + PA 3.2 (Process Deployment)	"Is the process defined organizationally and consistently deployed across projects?"
4	Predictable	CL3 + PA 4.1 (Quantitative Analysis) + PA 4.2 (Quantitative Control)	"Is the process measured and controlled using quantitative data?"
5	Optimizing	CL4 + PA 5.1 (Process Innovation) + PA 5.2 (Process Optimization)	"Is the process continuously improved using quantitative and innovation-driven methods?"

Process Attributes: The Measurement Instrument

Process Attributes (PAs) are the actual measurement instrument of the ASPICE framework. Each Capability Level beyond CL0 is defined by achieving specific PAs. Each PA is in turn assessed by looking at Generic Practices (GPs) and Generic Resources (GRs) - the PAM-defined indicators that provide evidence of PA satisfaction.

There are 9 Process Attributes in total across CL1–CL5:

PA ID	Name	CL Required	Focus
PA 1.1	Process Performance	CL1	Are the Base Practices being performed and the process outcomes being achieved?
PA 2.1	Performance Management	CL2	Is the process execution planned and monitored? Are objectives set and deviations acted on?
PA 2.2	Work Product Management	CL2	Are work products identified, documented, controlled, and reviewed?
PA 3.1	Process Definition	CL3	Does an organizational standard process exist that the project process is derived from?
PA 3.2	Process Deployment	CL3	Is the standard process consistently deployed across projects with defined tailoring?
PA 4.1	Quantitative Analysis	CL4	Is the process analyzed using quantitative measures? Are performance baselines established?
PA 4.2	Quantitative Control	CL4	Is the process controlled within defined quantitative bounds? Are deviations detected and corrected?
PA 5.1	Process Innovation	CL5	Are innovative improvements identified from analysis of process weaknesses and technology changes?
PA 5.2	Process Optimization	CL5	Are identified improvements implemented, evaluated, and sustained?

PA Attribute Outcomes

Each PA is further decomposed into Attribute Outcomes (AOs) that define what achieving the PA means. For example, PA 2.1 has these Attribute Outcomes:

AO 2.1.1 - Objectives for the performance of the process are identified
AO 2.1.2 - Performance of the process is planned and monitored
AO 2.1.3 - Performance of the process is adjusted to meet plans
AO 2.1.4 - Responsibilities and authorities for performing the process are defined, assigned, and communicated
AO 2.1.5 - Resources and information necessary for performing the process are identified, made available, allocated, and used
AO 2.1.6 - Interfaces between the involved parties are managed to ensure effective communication and clear assignment of responsibility

An assessor evaluates every AO individually, rates it N/P/L/F, and aggregates to a PA rating. If any AO is rated N or P, the PA cannot be Largely or Fully achieved - and the CL that depends on that PA cannot be claimed.

N/P/L/F Rating Scale Explained

The N/P/L/F scale is defined in ISO/IEC 33020. It is an ordinal scale applied to each Process Attribute based on the degree of achievement of its Attribute Outcomes. The percentages are approximate and represent the assessor's judgment of coverage across all indicators.

Rating	Label	Range	Practical Meaning
N	Not Achieved	0–15%	Little or no evidence. The attribute is essentially absent. Most indicators missing or not demonstrated.
P	Partially Achieved	15–50%	Some evidence exists but coverage is incomplete. Some BPs or AOs demonstrated but significant gaps remain.
L	Largely Achieved	50–85%	Most evidence present. Minor weaknesses only - not affecting the overall purpose. Acceptable for CL achievement with noted findings.
F	Fully Achieved	85–100%	Comprehensive evidence. All or nearly all indicators demonstrated. No significant gaps.

CL Achievement Rules Using N/P/L/F

The following rules define when a Capability Level is "achieved":

All PAs at the target CL must be rated L or F
All PAs at all lower CLs must be rated F (not just L)
Example: To achieve CL2 for SWE.1 - PA 1.1 must be F, AND PA 2.1 must be L or F, AND PA 2.2 must be L or F
To achieve CL3 - PA 1.1 must be F, PA 2.1 and 2.2 must be F, PA 3.1 and 3.2 must be L or F

⚠️ The F Requirement for Lower Levels

This is one of the most commonly misunderstood rules. A project that achieves PA 1.1 = L (Largely) and PA 2.1 = L, PA 2.2 = L does NOT achieve CL2. PA 1.1 must be F to proceed to CL2. Getting to "Largely" on your base practices is not enough - you need them Fully achieved before the managed practices on top count. This is why teams can have strong CL1 evidence but still fail to achieve CL2.

CL0 & CL1: Incomplete vs Performed

CL0 - Incomplete Process

A process at CL0 either does not exist or fails to achieve its purpose. PA 1.1 is rated N or P. In practice, CL0 means there is no credible evidence that the process is being executed. For an engineering process like SWE.1, CL0 would mean: no identifiable software requirements document, no traceability, no review - the team is coding directly from informal conversation.

CL0 is rare in established companies but common in very early-stage startups or teams that have never been audited. It is an immediate disqualifier for new business awards at German OEMs.

CL1 - Performed Process

CL1 means PA 1.1 is rated Fully. The process achieves its intended purpose - all (or nearly all) Base Practices are performed and the process outcomes are observable. Work products exist. The process "works," but there is no evidence of systematic planning, management, or organizational consistency.

For SWE.1 at CL1, assessors will look for:

A software requirements specification exists with identifiable requirements
Requirements have unique IDs
Traceability exists to system requirements (even if informal - a comment in the SRS linking to a STS item)
Verification criteria defined (even if in the SRS itself)
Evidence of review (review meeting minutes or sign-off)
Requirements distributed to the development team

What CL1 does not require: a formal plan for the requirements process, documented resource allocation, tracking of open issues to closure, a configuration management baseline of the SRS. Those are CL2 requirements.

💡 CL1 Reality Check

A surprising number of projects that believe they are "comfortably at CL2" are actually at CL1 - or even CL1-Partially - on key SWE processes. This is because CL1 BPs (especially BP6: bidirectional traceability) are frequently incomplete. Requirement IDs exist but the upstream link to system requirements is missing, or 30% of requirements have no test coverage in SWE.6. That is PA 1.1 rated P - not F - and CL1 is not achieved.

CL2: Managed Process - Generic Practices Deep Dive

CL2 is the most practically important level. It is the minimum contractual requirement for most ECU software projects and represents the shift from "the process works" to "the process is managed." The distinction is about discipline, predictability, and accountability - not technical skill.

CL2 requires PA 2.1 (Performance Management) and PA 2.2 (Work Product Management), each rated L or F, on top of CL1 already fully achieved.

PA 2.1 - Performance Management: Generic Practices

The PAM defines Generic Practices (GPs) for PA 2.1. These apply to every process in scope - they are not process-specific. For every process being assessed at CL2, the assessor will check all of these:

GP ID	Generic Practice	What It Means in Practice	Evidence to Collect
GP 2.1.1	Identify the objectives for the performance of the process	Each process has documented, measurable objectives. Not "we will write good requirements" - but "SWE.1 will produce a reviewed, baselined SRS by milestone M2 with ≥95% requirements coverage of SYS.2."	Project plan sections with process objectives, project quality plan, scoping document with process goals
GP 2.1.2	Plan the performance of the process to fulfill the identified objectives	A process execution plan exists - schedule, activities, dependencies, resource assignments. The plan is specific enough to manage against.	Project schedule with SWE.1 milestones, work breakdown structure, sprint plan if Agile
GP 2.1.3	Monitor the performance of the process against the plans and adjust the plans if necessary	Actual vs planned tracking is performed and documented. When deviations occur, a corrective action is logged and tracked to closure.	Status reports, project steering committee minutes, issue/action log, updated schedule with actuals
GP 2.1.4	Define responsibilities and authorities for performing the process	It is clear who is responsible for each activity (not just implied by org chart). RACI or equivalent is documented.	Project RACI matrix, project charter, role descriptions in the project plan
GP 2.1.5	Identify and make available resources to perform the process according to plan	Resources (people, tools, time) were explicitly identified and allocated. Tool licenses, lab time, and personnel availability were planned.	Resource plan, tool availability records, training records for specific competencies
GP 2.1.6	Manage the interfaces between involved parties	Communication interfaces between teams (e.g., between requirements engineers and architects) are defined. Meeting cadences, escalation paths, and responsibility boundaries are explicit.	Communication plan, interface agreement documents, review meeting records showing cross-team participation

PA 2.2 - Work Product Management: Generic Practices

GP ID	Generic Practice	What It Means in Practice	Evidence to Collect
GP 2.2.1	Define requirements for the work products of the process	Before the work product is created, its required content and structure are defined. Templates, checklists, or quality criteria specify what the WP must contain.	Work product templates, review checklists, WP content requirements in the process guideline
GP 2.2.2	Define requirements for documentation and control of the work products	The WP must be under configuration management - versioned, baselined at milestones, stored in a controlled repository. The CM plan covers this WP.	CM plan, version control system showing WP history, baseline records
GP 2.2.3	Identify, document, and control the work products	The WP has a unique identifier, is stored in the designated CM system, and version history is traceable. Anyone can retrieve the version that was baselined at any given milestone.	Version control logs, document ID scheme, baseline manifests
GP 2.2.4	Review and adjust work products to meet defined requirements	Work products are reviewed (peer review, inspection, or walkthrough). Review findings are logged, dispositioned, and the WP is updated accordingly. The review is documented - not just verbally confirmed.	Review records (issue list, attendees, date, reviewed version), updated WP after review, open issue tracker showing disposition of all review comments

🔍 The #1 CL2 Failure: GP 2.2.4

The most common reason a process fails to achieve CL2 in real assessments is GP 2.2.4: work products are not formally reviewed, or reviews are done but not documented, or review findings are not tracked to closure. "We reviewed it in a meeting" is not sufficient evidence. The assessor needs to see: who attended, which version was reviewed, what issues were found, how each was resolved, and that the final version incorporates the resolutions. This requires a review record - even a simple spreadsheet works if it contains all these elements.

CL3: Established Process - Organizational Standard

CL3 represents a qualitative shift from project-level management to organizational-level consistency. At CL2, each project can manage its own process however it likes, as long as it plans and tracks. At CL3, there is an organizational standard process that all projects derive from - and project-specific tailoring is controlled and documented.

PA 3.1 - Process Definition

PA 3.1 requires that a standard process (also called a "defined process" or "organizational standard") exists at the organizational level. This is typically implemented through a Quality Management System (QMS) or Process Asset Library. What must exist:

An organizational standard process describing how the process is performed across all projects
Process description with activities, roles, inputs, outputs, entry and exit criteria
Standard work product templates that all projects use as a baseline
Tailoring guidelines that define what can be tailored per project and under what conditions
Evidence that the standard was defined based on experience from past projects (process improvement inputs)

PA 3.2 - Process Deployment

PA 3.2 requires that the standard process is consistently deployed across projects. The assessor will look across multiple projects (not just the assessed one) to verify:

Each project has a documented tailored version of the standard process
Tailoring decisions are justified and approved (not arbitrary deviations)
People performing the process have been trained in the standard and know how to tailor it
Process performance data is fed back to the organizational standard for continuous improvement

CL3 in Practice: The Investment Required

CL3 requires organizational infrastructure that goes beyond a single project team. A QMS (often ISO 9001-based) is typically the backbone. The QMS must contain live, current process descriptions - not documents that were written five years ago and never updated. Process owners must be assigned and accountable for keeping the standard current. Training records must show that process users are trained.

This is why CL3 is achievable but expensive for smaller Tier-2 suppliers. It requires dedicated process engineering resources, a structured QMS, and organizational commitment that runs across projects - not just within one development team.

CL4 & CL5: Predictable & Optimizing

CL4 - Predictable Process

At CL4, the organization moves from knowing what the process does (CL3) to being able to predict its performance quantitatively. PA 4.1 (Quantitative Analysis) requires that process performance data is systematically collected, analyzed, and used to establish performance baselines. PA 4.2 (Quantitative Control) requires that when the process drifts outside defined quantitative boundaries, it is detected and corrected before outcomes are impacted.

In practice, CL4 means: you have historical data on defect injection rates per requirement, test execution productivity, review effectiveness (defect density per review hour), and you use this data to make quantitative predictions about project outcomes. Statistical Process Control (SPC) techniques - control charts, trend analysis, process capability indices - are applied.

CL4 is rare in the automotive supplier industry. Only a small number of Tier-1 suppliers achieve CL4 on any process, and it is not a standard OEM requirement outside of the most safety-critical or high-volume programs.

CL5 - Optimizing Process

CL5 represents continuous, innovation-driven improvement. PA 5.1 (Process Innovation) requires that the organization actively identifies opportunities for process improvement based on analysis of weakness data, technology trends, and industry benchmarks. PA 5.2 (Process Optimization) requires that identified improvements are implemented, their effects measured, and learning is institutionalized.

CL5 is essentially theoretical in most automotive supplier contexts. No major OEM requires CL5 for supplier qualification, and there is no widely documented case of a Tier-1 sustaining CL5 across a significant process portfolio. It is included in the model for completeness and to provide a long-term improvement target.

CL Achievement Rules & Common Failures

The Strict Cumulative Rule

The CL achievement rules are non-negotiable and cumulative. Here is the exact algorithm an assessor applies:

Rate every PA at every level (1.1 through 5.2) for the process using the N/P/L/F scale
For the target CL: all required PAs at that CL must be rated L or F
For all PAs below the target CL: they must all be rated F (not just L)
If step 2 passes but step 3 fails (a lower-level PA is only L, not F), the target CL is not achieved
The achieved CL is the highest level where all conditions in steps 2 and 3 are met

Most Common CL Failures by Level

Level	Most Common Failure Point	Root Cause
CL1	PA 1.1 rated P due to incomplete traceability (SWE.1 BP6, SWE.6 BP5) or missing review evidence (GP 2.2.4 precondition)	Traceability coverage gaps; review meetings undocumented
CL2	GP 2.1.3 - no documented monitoring of process performance against plan; or GP 2.2.4 - reviews done but not recorded	Teams track informally in their heads; review meetings not minuted
CL2	PA 2.2 fails because work products are not under CM control - SRS updated ad-hoc without version control	Git used for code but not for documents; document management discipline inconsistent
CL3	PA 3.1 fails because QMS exists but is outdated - process descriptions don't match actual practice	QMS written during a certification effort and never maintained; reality diverged from documentation
CL3	PA 3.2 fails because tailoring decisions are undocumented - teams deviate from standard process without recording why	Tailoring treated as informal - "we always do it this way on this project" without formal justification

💡 The Practical CL2 Readiness Checklist

Before claiming CL2 for any process, verify all of the following:

✅ All BPs performed and work products exist with adequate content (PA 1.1 = F)
✅ Process objectives documented in project plan or quality plan (GP 2.1.1)
✅ Process activities scheduled with milestones in project plan (GP 2.1.2)
✅ Status tracking meetings held with documented actuals vs. plan (GP 2.1.3)
✅ Roles and responsibilities for the process explicitly assigned (GP 2.1.4)
✅ Work product templates defined and used (GP 2.2.1)
✅ Work products in version control, baselined at milestones (GP 2.2.2, GP 2.2.3)
✅ Formal review records exist for each work product - with issue log and disposition (GP 2.2.4)

Summary & Key Takeaways

✅ Key Takeaways

CL is a per-process rating, not an organization-wide score. A project can have SWE.1 at CL2 and MAN.3 at CL1 simultaneously.
CL is strictly cumulative. Lower-level PAs must be F (not just L) before the next CL can be claimed.
PA 1.1 measures Base Practice performance (CL1). PA 2.1 measures process planning and monitoring. PA 2.2 measures work product management. All three are required for CL2.
CL2's most common failure point is GP 2.2.4 - undocumented reviews - and GP 2.1.3 - no evidence of monitoring against plan.
CL3 requires an organizational standard process and consistent deployment across projects - it cannot be faked on a project-by-project basis.
CL4 and CL5 require quantitative process management and are rarely demanded or achieved in the automotive supplier industry.

Quick Rating Guide: "What CL is this project?"

Evidence Available	Likely Rating
No requirements document, no traceability, no reviews	CL0
Requirements document with IDs and content, some traceability, evidence of reviews	CL1 (if all BPs sufficiently covered)
CL1 + documented process plan, status tracking, CM-controlled WPs with review records	CL2
CL2 + organization-wide standard process, tailoring records, cross-project consistency	CL3
CL3 + quantitative performance baselines, SPC-based monitoring	CL4

What's Next

The next chapter covers Base Practices and Generic Practices in depth - walking through the full BP and GP catalog for the HIS-scope processes, with worked examples of what evidence satisfies each indicator.

What's Next

Continue to Base Practices & Generic Practices to see the complete indicator catalog for each HIS-scope process, with worked examples of acceptable vs. insufficient evidence for each practice.