ISO/IEC 15504: ISO/IEC 15504 – Tutorial (about 60 minutes)

ISO/IEC 15504 is the international standard series, nicknamed SPICE, that first gave the world a common way to assess software and system development processes and rate their capability on a six-level scale. Every part of it has now been withdrawn and replaced by the ISO/IEC 330xx family, yet its ideas, vocabulary and assessment reports still shape contracts, supplier audits and sector models such as Automotive SPICE. After this tutorial you will be able to read and interpret a 15504-based assessment, explain how the series was built, and move old commitments and results onto the current standards with confidence.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: ISO/IEC 15504 "Information technology – Process assessment" was published by ISO and IEC through their joint committee for software and systems engineering (ISO/IEC JTC 1/SC 7). It first appeared as a nine-part Technical Report in 1998; the International Standard parts followed from 2003 (Part 2) to 2006 (Part 5), and Parts 6 to 10 were added between 2008 and 2012 (Part 6 was then revised in 2013). No part is current any more. The parts were withdrawn one by one as the ISO/IEC 330xx family replaced them: Part 1 (2004) was replaced by ISO/IEC 33001:2015 in February 2015, Part 2 (2003) by ISO/IEC 33002, 33003, 33004 and 33020 in March 2015, Part 7 by ISO/IEC 33001 to 33004 and ISO/IEC TR 33014 in the same month, Part 3 by ISO/IEC TS 33030 in 2017, Parts 4 and 9 by ISO/IEC TR 33015 in 2019, Parts 6 and 8 by ISO/IEC TS 33060 and TS 33074 in 2020, Part 5 by ISO/IEC TS 33061 in 2021, and the last remaining part, the Part 10 safety extension, by ISO/IEC TS 33064:2025 on 2025-10-21. This tutorial therefore teaches ISO/IEC 15504 as a legacy standard: what it said, why it matters today, and how each part maps to its successor. Status verified 2026-10-29 from the IEC webstore record of each part, which gives its publication date, withdrawal date and replacing documents.

Who it is for: quality and process engineers, supplier-quality and procurement staff, software and systems engineers, project managers and auditors who meet "ISO/IEC 15504" or "SPICE level 2" in a contract, an old assessment report, a customer requirement or a sector model, and need to understand what it really means.

Prerequisites: none. A rough idea of how software or system projects are planned and delivered helps, but every term is explained when it first appears. If you want the current method in depth, the companion SPICE course on this site teaches the ISO/IEC 330xx family; this course concentrates on the 15504 series itself and the bridge to its successors.

By the end of this tutorial:

You will be able to explain why ISO/IEC 15504 was created, how it evolved from a technical report into a ten-part standard, and why it was withdrawn.
You will be able to describe the role of each part and the architecture that links a process reference model, a measurement framework and a process assessment model.
You will be able to name the six capability levels and nine process attributes of Part 2 and apply the N-P-L-F rating rules to derive a capability level.
You will be able to outline how a conformant 15504 assessment was planned, performed and reported, and who was accountable for it.
You will be able to read a legacy 15504 assessment report critically and judge what it can and cannot still prove.
You will be able to map each 15504 part to its ISO/IEC 330xx successor and plan the migration of contracts, procedures and assessment models.

Lesson 1 – Origins, purpose and why it is now legacy

The problem the series set out to solve

By the early 1990s, large buyers of software, such as defence ministries, telecom operators and car makers, had learned that the quality of a delivered system depends heavily on how it was built. Disciplined requirements, planning, configuration control and testing tend to produce systems that work; improvisation tends to produce late, faulty ones. Buyers therefore wanted to look inside a supplier's development processes before signing a contract, and suppliers wanted to know where to improve.

Several assessment methods already existed: the Capability Maturity Model (CMM) for software from the Software Engineering Institute in the United States, and European schemes such as Bootstrap and Trillium. Each had its own vocabulary, scale and rules, so results could not be compared, and a supplier selling internationally could face several different assessments of the same work. The software engineering community asked ISO and IEC for one international standard for process assessment that would allow results to be compared and reused.

The SPICE project and the technical report

In 1993 the joint committee launched a project to develop that standard and gave it the acronym SPICE: Software Process Improvement and Capability dEtermination. The project tested its drafts in practice: the SPICE trials collected data from real assessments in many countries from the mid-1990s and fed the lessons back into the text. The first published result, in 1998, was ISO/IEC TR 15504, a nine-part Technical Report. A Technical Report is not a full standard; it signals that the material is useful but still maturing.

The 1998 report contained its own catalogue of processes. During the conversion into an International Standard, the committee made a decisive architectural change: the standard would no longer own a fixed list of processes. Instead it would define requirements and a measurement framework, and borrow its processes from life cycle standards such as ISO/IEC 12207 (software life cycle processes) and ISO/IEC 15288 (system life cycle processes). That decision is the key to understanding everything that followed.

The International Standard years

The International Standard was published in parts. Part 2, the only normative part of the core set, came first in 2003; Parts 1, 3 and 4 followed in 2004 and the exemplar software assessment model, Part 5, in 2006. Further parts were added for system life cycle processes, organisational maturity, IT service management, target process profiles and safety. For roughly a decade, "ISO/IEC 15504" was the name buyers wrote into contracts when they wanted an internationally recognised process assessment, and several industries built their own sector models on top of it.

Why it became legacy

Over time the committee found the structure awkward. Concepts, requirements and the measurement framework were mixed in Part 2; capability was the only characteristic that could be measured; and new needs, such as assessing other process qualities or defining maturity models, did not fit neatly. From 2015 the material was restructured into the ISO/IEC 330xx family, which separates concepts, requirements, measurement frameworks, assessment models and guidance into distinct documents. As each 330xx document was published, the matching 15504 part was withdrawn. The process took a decade: the last 15504 part, the safety extension, was withdrawn in October 2025.

Why it still matters

A withdrawn standard does not vanish from the world. You will still meet ISO/IEC 15504 in at least five places:

Supplier contracts and quality agreements written before the migration that still require "ISO/IEC 15504 capability level 2" or "SPICE level 3".
Historical assessment reports kept as evidence in supplier files, tender documents or audit trails.
Older versions of sector models, notably Automotive SPICE up to version 2.5, which used the 15504 measurement framework directly.
Internal process handbooks, training material and tools that still use 15504 names for levels and attributes.
Research papers and textbooks, which mostly describe the 15504 era because it lasted so long.

Understanding the series lets you interpret those documents correctly and translate them into the current standards without losing their meaning.

Figure 1 – The life of ISO/IEC 15504, from the SPICE project to the withdrawal of its last part.

Lesson 2 – Key concepts and vocabulary

Process assessment uses a precise vocabulary, and many disputes about old assessment results come from people using these words loosely. The explanations below are plain-language descriptions, not the formal definitions of the standard.

Process – a set of related activities that turns inputs into outputs to achieve a stated purpose, for example requirements analysis, project management or configuration management.
Process assessment – a disciplined evaluation of an organisation's processes against a process assessment model, carried out by a team that rates the processes from objective evidence.
Process purpose – the high-level objective a process exists to achieve, written in one or two sentences in a reference model.
Process outcome – an observable result of successfully achieving a process purpose, such as "a baseline of requirements is established".
Process reference model (PRM) – a catalogue of processes, each described by its purpose and outcomes, together with a description of how the processes relate. In the 15504 era the software PRM came from ISO/IEC 12207 and the system PRM from ISO/IEC 15288.
Measurement framework – the scale used to rate processes. In ISO/IEC 15504-2 it was the capability scale: six capability levels made up of nine process attributes.
Process capability – how well a process is able to meet current or projected business goals in a consistent way.
Capability level – a point on the six-step scale from 0 (incomplete) to 5 (optimizing) that summarises the capability of one process.
Process attribute (PA) – a measurable property of process capability, such as performance management or process definition, that applies to any process. Each capability level from 1 upwards is defined by one or two attributes.
Process assessment model (PAM) – the assessor's working tool. It takes processes from a PRM and the capability scale from the measurement framework, and adds indicators that show what evidence to look for. ISO/IEC 15504-5 was the exemplar PAM for software.
Assessment indicator – a source of objective evidence that supports an assessor's judgement. Process performance indicators (base practices and work products) relate to Level 1; process capability indicators (generic practices and generic resources) relate to Levels 1 to 5.
Objective evidence – documents, records, tool data and interview statements that show a practice is actually carried out, as opposed to claims or intentions.
Process profile – the set of process attribute ratings for the processes assessed; the primary output of an assessment.
Target capability profile – the capability a sponsor wants for selected processes, used as a yardstick in capability determination.
Assessment sponsor – the person or organisation that requests and pays for the assessment, defines its purpose and receives its results.
Competent assessor – the assessor in a 15504 assessment who had demonstrated the required competence and was accountable for the assessment conforming to the standard.
Conformity – meeting the stated requirements. In 15504 it applied to assessments, PRMs and PAMs, never to whole organisations in the way ISO 9001 certification does.

Two purposes, one method

The acronym names the two uses of an assessment. Process improvement is an organisation examining its own processes to find strengths and weaknesses and decide what to change. Capability determination is someone, usually a customer, judging whether a supplier's processes are capable enough for a planned piece of work and what risk remains if they are not. Both purposes use the same measurement framework and the same kind of evidence; what differs is who sponsors the assessment, how the scope is chosen and what is done with the profile afterwards.

Processes, not products or people

A 15504 assessment rated processes in a defined organisational unit, such as a department, a product line or a group of projects. It did not rate products, it did not grade individual engineers, and it did not certify the company. Keeping this distinction in mind protects you from the most common misreading of old reports: treating a process profile as a quality certificate for the whole company.

Lesson 3 – Structure of the 15504 series

The ten parts

The International Standard series grew to ten parts. The titles below are paraphrased; editions are the last ones published before withdrawal.

Part	Last edition	Role (paraphrased)
Part 1	2004	Concepts and vocabulary: the shared terms and an overview of how the series fits together.
Part 2	2003	Performing an assessment: the normative requirements for assessments, for process reference models and assessment models, and the capability measurement framework.
Part 3	2004	Guidance on performing an assessment, including assessor competence and how to meet Part 2 in practice.
Part 4	2004	Guidance on using assessment results for process improvement and for capability determination.
Part 5	2012	An exemplar process assessment model for software life cycle processes, based on ISO/IEC 12207.
Part 6	2013	An exemplar process assessment model for system life cycle processes, based on ISO/IEC 15288.
Part 7	2008 (TR)	Assessment of organisational maturity: deriving a maturity level from the capability of defined sets of processes.
Part 8	2012 (TS)	An exemplar process assessment model for IT service management, based on the ISO/IEC 20000 reference model.
Part 9	2011 (TS)	Target process profiles: how to define the capability wanted for improvement or capability determination.
Part 10	2011 (TS)	Safety extension: additional safety-related processes, such as safety management and safety engineering, for use with the Part 5 and Part 6 models.

"TR" marks a Technical Report and "TS" a Technical Specification; both are lighter-weight ISO/IEC document types than a full International Standard. Notice that only Part 2 contained hard requirements in the core set. Everything else either explained Part 2, guided its use, or offered an example model that conformed to it.

The two-dimensional architecture

The central idea of 15504 is that an assessment looks at two independent dimensions. The process dimension answers "which processes are we examining?" and comes from a process reference model. The capability dimension answers "how well is each process performed and managed?" and comes from the measurement framework in Part 2. A process assessment model joins the two and adds indicators so that assessors know what evidence to seek.

Because the process dimension was borrowed, the same capability scale could be applied to software, systems, IT services, automotive electronics, space projects or medical devices, as long as someone wrote a reference model and an assessment model that met the Part 2 requirements. That is why so many sector models grew from 15504, and why their results remained broadly comparable.

Figure 2 – How the parts fit together: a reference model and the measurement framework combine into an assessment model, whose results feed improvement or capability determination.

The capability scale of Part 2

Part 2 defined six capability levels. Each level above zero is defined by one or two process attributes, and each attribute is rated separately.

Level 0 – Incomplete process. The process is not implemented or fails to achieve its purpose. There is little or no evidence of systematic achievement.
Level 1 – Performed process. The process achieves its purpose; its outcomes are produced. Attribute PA 1.1 Process performance.
Level 2 – Managed process. The performed process is planned, monitored and adjusted, and its work products are properly established, controlled and maintained. Attributes PA 2.1 Performance management and PA 2.2 Work product management.
Level 3 – Established process. The managed process follows a defined standard process, tailored for each use, and the organisation learns from its deployment. Attributes PA 3.1 Process definition and PA 3.2 Process deployment.
Level 4 – Predictable process. The established process operates within defined limits, using measurement and control to achieve its outcomes. Attributes PA 4.1 Process measurement and PA 4.2 Process control.
Level 5 – Optimizing process. The predictable process is continuously improved to meet relevant current and projected business goals. Attributes PA 5.1 Process innovation and PA 5.2 Process optimization.

Figure 3 – The six capability levels of ISO/IEC 15504-2 and the process attributes that define each level.

The rating scale and level rules

Each process attribute was rated on a four-point ordinal scale based on the extent of achievement shown by the evidence:

N – Not achieved: 0 to 15 percent achievement.
P – Partially achieved: more than 15 up to 50 percent.
L – Largely achieved: more than 50 up to 85 percent.
F – Fully achieved: more than 85 up to 100 percent.

The percentages are not measurements in a statistical sense; they describe how much of the attribute's intent is demonstrated, judged by trained assessors. The capability level of a process then follows a simple rule. A process reaches a given level when the attributes of that level are rated at least L and every attribute of all lower levels is rated F. So a process with PA 1.1 = F, PA 2.1 = L and PA 2.2 = F is at Level 2. If PA 2.1 had been P, the process would be at Level 1, however good its work product control. And if PA 1.1 were only L, the process could not be higher than Level 1, because Level 2 requires the lower attribute to be fully achieved.

This rule explains a pattern that confuses newcomers: a process can show many Level 3 behaviours, such as a documented organisational standard, and still be rated Level 1, because the basics of planning and monitoring at Level 2 are not fully in place. The scale is cumulative; higher levels build on the lower ones.

Inside an assessment model

Part 5, the exemplar software model, shows how a PAM turns this framework into something assessors can use. For every process it repeated the purpose and outcomes from the reference model and added base practices (activities that, when carried out, contribute to the outcomes) and typical work products (outputs and inputs that are evidence of the process). For every attribute it added generic practices and generic resources that apply to any process. The 2006 edition grouped processes into categories with short identifiers, for example engineering, management and support processes; the 2012 edition aligned the process set with ISO/IEC 12207:2008.

Indicators are guidance, not a checklist. A team that achieves an outcome with a different but equivalent practice, or with a differently named work product, can still be rated well. Assessors judge whether the intent of the attribute is achieved, using indicators as prompts for what to look at.

Lesson 4 – How it worked in practice

The assessment process required by Part 2

Part 2 did not prescribe a single method. It stated requirements that any conformant assessment had to meet, and left room for different methods, from a one-day self-assessment to a multi-week independent assessment. The required activities were planning, data collection, data validation, process attribute rating and reporting.

Figure 4 – The activities a conformant ISO/IEC 15504 assessment had to cover, from the sponsor's input to the assessment record.

Step by step

Assessment input. Before planning, the sponsor documents the purpose (improvement, capability determination or both), the scope (which processes, which organisational unit, which projects or instances, and the highest capability level to examine), the constraints (time, confidentiality, availability of people), the PAM to be used, and the people involved and their roles.
Planning. The competent assessor and the team prepare a plan: schedule, team, participants to interview, documents to sample, how ratings will be derived and how results will be reported. The plan is agreed with the sponsor.
Data collection. Assessors interview practitioners and managers, examine work products and tool records, and map what they find to the indicators of the PAM. Good assessors look for consistent evidence across several projects, not one showcase.
Data validation. Collected data must be confirmed as accurate and sufficient for the scope. A common technique is a feedback session in which participants can correct factual errors before ratings are finalised.
Rating. The team rates each process attribute for each process in scope, records the evidence and reasoning behind each rating, and derives capability levels using the rules from Lesson 3.
Reporting. Results go to the sponsor: the process profile, strengths and weaknesses, and anything needed to interpret the result. The assessment record keeps the inputs, the date, the participants, the PAM used, the ratings and the identification of the competent assessor.

Roles

Sponsor – owns the purpose and scope, provides resources and receives the results.
Competent assessor – leads or oversees the assessment and confirms it meets Part 2; Part 3 described the education, training and experience such an assessor needed.
Assessment team members – collect and analyse evidence and take part in rating.
Participants – the practitioners and managers whose work is examined; they provide evidence and help validate findings.
Process owners and improvement staff – use the results afterwards to plan and implement change.

Using the results for improvement

Part 4 described improvement as a cycle. An organisation starts from its business needs, decides which processes matter most, assesses them, analyses the gaps between the current profile and the capability it needs, plans and implements changes, and then confirms that the changes worked, often with a follow-up assessment. The assessment is the diagnosis; the improvement programme is the treatment. A profile with no action plan behind it is wasted effort.

Using the results for capability determination

For capability determination, a customer first defines a target capability profile for the processes that matter to the planned work. Part 9 later gave detailed guidance on building such profiles. The supplier's processes are then assessed, or an existing recent assessment is reused if its scope fits. The gaps between target and assessed profile are analysed as risks: a requirements process at Level 1 where Level 2 was targeted signals a risk of uncontrolled requirement changes. The customer can then accept the risk, require an improvement plan, add contractual safeguards or choose another supplier. The outcome is a decision informed by process risk, not a pass-or-fail stamp.

Organisational maturity

Part 7 added a way to summarise many process profiles into an organisational maturity level, so that sponsors used to the staged approach of CMMI could express a single overall figure. It defined which sets of processes had to reach which capability levels for each maturity level. Most 15504 assessments, however, reported per-process profiles, which carry more information than a single number.

Lesson 5 – Assessment, certification and compliance

No certification of organisations

ISO/IEC 15504 never had an organisational certification scheme comparable to ISO 9001 or ISO/IEC 27001. There was no accredited certification body that issued a company a certificate valid for three years. An assessment produced a dated process profile for a defined scope and purpose. Statements such as "our company is SPICE certified" or "we are ISO 15504 Level 3" were always shorthand at best; at worst they misrepresented a profile for a few processes in one unit as a company-wide credential.

What could conform

Part 2 defined conformity for three things:

An assessment conformed if it met the Part 2 requirements for the process, roles, input, ratings and record.
A process reference model conformed if it described its domain, community of interest and processes in terms of purpose and outcomes, and met the other model requirements.
A process assessment model conformed if it covered processes from a conformant reference model, used the Part 2 measurement framework, provided indicators, and showed a mapping to both.

This is why sector models, such as Automotive SPICE, were careful to declare conformity with Part 2: it allowed their assessments to claim the international basis of 15504.

Assessor qualification

The standard required competent assessors but did not run a qualification scheme itself. Independent schemes filled the gap: national and international assessor certification programmes, training providers and, for the automotive sector, the intacs scheme (International Assessor Certification Scheme), which still trains and certifies Automotive SPICE assessors. These schemes certify people, not organisations.

Reading a legacy assessment report

If you are handed a 15504 assessment report today, ask these questions before relying on it:

Date. Process capability decays as teams, tools and leadership change. Some customers and sector schemes limit how long a result is accepted, often to a few years; check what your contract or sector says.
Scope. Which processes, which organisational unit, which projects were sampled, and up to which capability level?
Purpose and independence. Was it a self-assessment for improvement or an independent assessment for capability determination?
Model and framework. Which PAM and edition was used (Part 5:2006, Part 5:2012, Automotive SPICE 2.5) and which measurement framework?
Assessor. Who was the competent assessor, and what qualification did that person hold?
Evidence. Are ratings traceable to evidence, or does the report contain only levels?

Compliance today

Because every part is withdrawn, no new assessment can honestly claim conformity with ISO/IEC 15504 as a current standard. A new assessment should state conformity with ISO/IEC 33002 (requirements for performing process assessment), use a measurement framework that meets ISO/IEC 33003, such as ISO/IEC 33020 for capability, and use an assessment model that meets ISO/IEC 33004, such as ISO/IEC TS 33061 for software. Contracts that still name 15504 should be updated by agreement; until then, parties should write down how they interpret the old reference.

Lesson 6 – Worked example: retiring a 15504 contract clause

The situation

Nordlicht Controls (a fictional company) builds embedded control units and their software for industrial and agricultural machines. It has about 220 engineers in two sites. A quality agreement signed in 2014 with its largest customer, a tractor manufacturer, says: "The supplier shall demonstrate ISO/IEC 15504 capability level 2 for requirements engineering, software design, software testing, project management and configuration management." Nordlicht's last independent assessment, against ISO/IEC 15504-5:2012, dates from 2019. The customer's new supplier-quality manager asks for current evidence before awarding a new platform project.

Step 1 – Read the clause and the old report

The quality manager, Priya, starts by reading the 2019 report against the checklist from Lesson 5. The scope was one product line at one site, three projects sampled, up to Level 2. The profile shows requirements engineering, design and configuration management at Level 2; testing at Level 1 (PA 2.1 rated P because test planning was ad hoc); project management at Level 2. The competent assessor held a recognised assessor qualification. The report is seven years old and the second site was never assessed. Priya concludes that the report shows historical capability, not current capability, and does not cover the whole supplier.

Step 2 – Agree on the current basis with the customer

Priya explains to the customer that ISO/IEC 15504 has been withdrawn and proposes to interpret the clause through its successors: an assessment conforming to ISO/IEC 33002, using the ISO/IEC 33020 capability framework and the ISO/IEC TS 33061 software model. Because both parties work in a safety-relevant domain, she also mentions ISO/IEC TS 33064, the safety model that replaced the 15504 safety extension, for a later phase. The customer agrees and both sign a short amendment that names the new documents and keeps "capability level 2" as the target. Priya notes the attribute names that changed between 15504-2 and 33020 so that nobody is surprised: Levels 0 to 3 are essentially the same, while Level 4 and 5 attributes and the name of Level 5 were revised.

Step 3 – Define the target profile and scope

Together they write a target profile: the five processes at Level 2, which means PA 1.1 rated F and PA 2.1 and PA 2.2 rated at least L. They map the five processes named in the old clause to the process set of TS 33061, because the process names and boundaries differ from the 2012 edition of Part 5. The scope covers both sites and three current projects, one of them agile.

Step 4 – Prepare without gaming

Nordlicht runs an internal gap analysis six months before the independent assessment. The weakest area is again testing: test plans exist for some releases, but test effort is not monitored and test results are stored in personal folders. The improvement team introduces a lightweight test plan per release, tracks test progress on the team boards, and places test reports under configuration control. They do not write new procedures that nobody follows; they change how work is actually done and let the evidence accumulate for three months.

Step 5 – The assessment

An independent lead assessor plans the assessment with the customer as sponsor. The team interviews engineers and managers at both sites, samples requirements baselines, design reviews, test reports and change records, holds a validation session where participants correct two misunderstandings, and then rates the attributes. Results: requirements, design, configuration management and project management at Level 2; testing now at Level 2 with PA 2.1 rated L and PA 2.2 rated F. One weakness is recorded: the agile project's design reviews are inconsistent, giving design PA 2.2 an L rather than F, which still meets the target.

Step 6 – Decision and follow-up

The customer compares the new profile with the target, finds no gaps, records the remaining weakness as a low risk, and awards the project. Priya updates Nordlicht's process handbook to replace references to ISO/IEC 15504 with the 330xx documents, archives the 2019 report with a note explaining its historical status, and plans an improvement action for design reviews. The legacy clause has been retired without losing its intent: the customer still gets an internationally recognised, comparable view of process capability.

What the example shows

A legacy report is evidence of the past; its date, scope and model edition decide how much it is worth now.
Migrating from 15504 is mostly a matter of agreement and mapping, because the core ideas carried over.
Target profiles turn a vague "level 2" into precise attribute ratings for named processes.
Real improvement means changing daily work and letting evidence build up, not producing documents for the assessor.

Lesson 7 – Relationship to other standards and frameworks

Successors in the 330xx family

Every 15504 part has a successor or partial successor. The mapping is not always one to one: Part 2 was split into four documents, and guidance from Parts 4 and 9 was merged into ISO/IEC TR 33015, a technical report on process risk determination. When you migrate a document or a contract, check the current catalogue entry, because several 330xx documents have themselves been revised since 2015.

Figure 5 – Where each ISO/IEC 15504 part went: the successor documents in the ISO/IEC 330xx family.

Part 7, the organisational maturity report, does not appear in the figure because it has no single successor: it was withdrawn in March 2015 and its content was spread across the core documents ISO/IEC 33001 to 33004 and ISO/IEC TR 33014 (a guide for process improvement). Requirements for maturity models now sit in ISO/IEC 33004. If you depend on a Part 7 maturity rating, ask the body that issued it how it should be read today.

What changed in the move

Separation of concerns. Concepts, assessment requirements, measurement framework requirements, model requirements and the capability framework now sit in separate documents.
Generalisation. Capability became one example of a process quality characteristic; other characteristics can be measured with their own frameworks.
Revised upper levels. ISO/IEC 33020 renamed Level 5 from Optimizing to Innovating and redefined the Level 4 and 5 attributes around quantitative analysis, quantitative control and process innovation; the rating scale and the logic for Levels 1 to 3 remained familiar.
More guidance on rating. The successors added more explicit options for refining and aggregating ratings across process instances.

Neighbouring standards and models

Standard or model	What it is	Relationship to ISO/IEC 15504
ISO/IEC 330xx family	Current international standards for process assessment	Direct successor; keeps the two-dimensional architecture, the N-P-L-F scale and the capability levels, with restructured documents and revised upper-level attributes.
Automotive SPICE	Process assessment and reference model for automotive system and software development, maintained by the VDA Quality Management Center	Built on 15504: versions up to 2.5 used the 15504-2 measurement framework; version 3.0 onward uses ISO/IEC 33020. Its assessors are certified under intacs.
CMMI	Capability and maturity model maintained by ISACA (originally from the Software Engineering Institute)	Parallel approach with its own appraisal method and maturity and capability levels; 15504 was partly created to give an international alternative to CMM. Results are not directly interchangeable.
ISO/IEC/IEEE 12207 and 15288	Life cycle process standards for software and for systems	Supplied the process dimension: their purpose and outcome statements served as reference models for Parts 5 and 6.
ISO/IEC 20000	IT service management system standard	Its process reference model underpinned the Part 8 assessment model for IT service management.
ISO 9001	Quality management system requirements with third-party certification	Different purpose: certifies a management system against requirements, while 15504 rated the capability of individual processes. The two can complement each other.

Sector models

Beyond Automotive SPICE, several communities built models on the 15504 framework, for example for space projects, medical device software and software testing. When you meet one of these, check whether its current version has moved to the 330xx measurement framework and which version an old report used.

Common pitfalls and best practices

Pitfalls

Claiming current conformity with a withdrawn standard. Stating in 2026 that a new assessment "conforms to ISO/IEC 15504" misleads readers; cite the 330xx documents instead.
Treating a profile as a company certificate. A capability level belongs to a process in a defined scope at a point in time, not to the whole organisation forever.
Relying on old reports without checking date and scope. A seven-year-old assessment of one site says little about another site today.
Mixing level names across frameworks. 15504 "Optimizing", 33020 "Innovating" and the CMMI level names are not interchangeable; confusing them causes contract disputes.
Using indicators as a rigid checklist. Rating down a team that achieves outcomes with equivalent but differently named practices distorts the result.
Writing documents for the assessor. Procedures created just before an assessment without real use produce weak evidence and no lasting improvement.
Leaving legacy clauses untouched. Contracts that still reference 15504 invite argument about what evidence is acceptable.

Best practices

Map every legacy reference. Keep a simple table that maps each 15504 part your organisation cites to its current successor, and update handbooks and templates accordingly.
Agree interpretation in writing. When a contract names 15504, sign a short amendment that names the successor documents and the target profile.
Express targets as attribute ratings. Define target profiles per process and attribute, not as a single headline level.
Record the model edition and assessor. Every assessment record should name the PAM edition, the measurement framework and the competent assessor.
Trace ratings to evidence. Keep the link between each rating and the evidence behind it so the result can be reviewed and reused.
Validate findings with participants. A feedback session before final rating catches misunderstandings and builds trust in the result.
Use assessments to drive improvement. Follow every assessment with an action plan and a check that the changes worked.

Summary and key takeaways

ISO/IEC 15504, known as SPICE, was the first international standard for process assessment; it grew from a 1998 technical report into a ten-part series.
All parts are withdrawn; the ISO/IEC 330xx family replaced them between 2015 and 2025, when the safety extension became the last part to go.
The series rated processes on two dimensions: processes from a reference model such as ISO/IEC 12207, and capability from the Part 2 measurement framework.
Part 2 defined six capability levels, nine process attributes and the N-P-L-F scale; a level is reached when its attributes are at least L and all lower ones are F.
A conformant assessment covered planning, data collection, validation, rating and reporting, under an accountable competent assessor.
Results served process improvement or capability determination; there was never an organisational certificate.
Legacy reports and contract clauses must be read with their date, scope, model edition and assessor in mind.
Migration means mapping each part to its successor, agreeing interpretation with partners and updating internal documents.

Reflection questions

Your organisation's supplier manual still asks for "ISO/IEC 15504 Level 3" from key suppliers. What would you change in the wording, and which successor documents would you name?
A supplier sends you a 2017 assessment report showing Level 2 for all processes. Which details in the report would you check before accepting it, and why?
Explain to a project manager why a process can show many Level 3 characteristics and still be rated Level 1.
Pick one process from your own work. What objective evidence would show that its work products are properly managed?
For a planned subcontract in your field, which three processes would you put in a target profile, and what risk would a gap in each one create?