ISO/IEC 330xx: ISO/IEC 330xx – Tutorial (about 60 minutes)

ISO/IEC 330xx is the family of international standards that tells you how to assess processes in a disciplined, repeatable way: what an assessment must include, how process models must be built, and how to turn evidence into ratings such as a process capability level. It is used by software and systems organisations, IT service providers, their customers and the people who write industry models such as Automotive SPICE. After this tutorial you will be able to explain how the family is organised, read a capability profile, plan a conformant assessment and use the results for improvement or supplier decisions.

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

Course overview

Edition and status: "ISO/IEC 330xx" is not one document with a single edition; it is the name for the set numbered ISO/IEC 33001 to 33099, owned by the joint ISO and IEC committee JTC 1/SC 7 (Software and systems engineering). The core parts are ISO/IEC 33001:2015 (concepts and terminology), ISO/IEC 33002:2015 (requirements for performing process assessment), ISO/IEC 33003:2015 (requirements for process measurement frameworks), ISO/IEC 33004:2015 (requirements for process reference, process assessment and maturity models) and ISO/IEC 33020:2019 (the process measurement framework for process capability, second edition, which replaced the 2015 edition). ISO catalogue records list all five (33001, 33002, 33003, 33004 and 33020) at stage 90.93, reviewed and confirmed in 2026, so these editions remain current and none is being revised. Supporting documents include ISO/IEC TS 33010:2023 (guidance for performing process assessments), ISO/IEC TR 33014:2013 (guide for process improvement), ISO/IEC TR 33018:2019 (guidance for assessor competency), ISO/IEC TS 33030:2017 (an exemplar documented assessment process), and process assessment models such as ISO/IEC TS 33061:2021 (software life cycle), ISO/IEC TS 33060:2025 (system life cycle, second edition), ISO/IEC TS 33062:2025 (quantitative processes for the higher capability levels) and ISO/IEC TS 33072:2016 (information security management). The family replaced the older ISO/IEC 15504 (SPICE) series. Verified 2026-10-29 from the ISO JTC 1/SC 7 catalogue and the ISO records of each core part; ISO standards are copyrighted, so this tutorial explains them in its own words.

Who it is for: quality and process managers, software and systems engineers, project and delivery managers, supplier quality and procurement staff, internal auditors, and anyone who has been asked to "get assessed" or to judge a supplier's assessment result. It is also a good foundation if you will later study a specific model built on the family, such as Automotive SPICE.

Prerequisites: none. It helps if you have worked in a team that follows some defined way of working, because the family is all about describing, measuring and improving such ways of working.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the four diagrams, then spend the remaining time on the worked example and the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why the ISO/IEC 330xx family exists, what problem it solves and how it grew out of ISO/IEC 15504.
You will be able to describe the roles of the main documents and how a process reference model, a process assessment model and a process measurement framework fit together.
You will be able to name the six capability levels of ISO/IEC 33020:2019, describe what the process attributes at each level cover and derive a capability level from attribute ratings.
You will be able to outline the activities, roles and inputs of an assessment that conforms to ISO/IEC 33002, including the three classes of assessment.
You will be able to interpret assessment results correctly and explain why they are ratings for a defined scope rather than a certificate.
You will be able to relate the family to ISO/IEC 15504, Automotive SPICE, CMMI, ISO 9001 and the life cycle standards ISO/IEC/IEEE 12207 and 15288.

Lesson 1 – Origins, purpose and scope

The question behind process assessment

Every organisation that builds systems or delivers services has processes: the repeated ways in which it plans work, manages requirements, controls versions, tests, releases and supports. Some of those processes work well and keep working when people change; others depend on a few experienced individuals and fall apart under pressure. Managers, customers and regulators all want to know which is which. Is the supplier you are about to trust with a safety-relevant component really able to control its changes? Will your own improvement programme make a measurable difference, or only produce more documents?

Answering such questions with opinions is easy and unreliable. Two consultants looking at the same team can reach very different conclusions if they use different checklists, ask different people and interpret evidence differently. Process assessment exists to make that judgement systematic: you compare what an organisation actually does against a defined model, you collect objective evidence, and you express the result on an agreed scale. The ISO/IEC 330xx family is the international rulebook for doing that consistently.

From SPICE to ISO/IEC 15504 to ISO/IEC 330xx

In the 1990s an international project called SPICE (Software Process Improvement and Capability dEtermination) brought together researchers, assessors and industry to create a common standard for software process assessment. Its results were published first as technical reports and later, in the 2000s, as the multi-part International Standard ISO/IEC 15504. That series introduced ideas that are still central today: a process dimension taken from a reference model, a separate capability dimension with levels and attributes, and assessments rated on a four-point scale.

ISO/IEC 15504 was successful, but it mixed several concerns in the same documents: general requirements, a specific capability scale, guidance and example models. As more communities wanted to assess processes outside software (services, information security, enterprise processes) and to measure things other than capability, the committee decided to restructure the material. From 2015 the ISO/IEC 330xx family progressively replaced and extended the 15504 parts. For example, ISO/IEC 33001 replaced 15504-1; 15504-2 was replaced by 33002, 33003, 33004 and the first edition of 33020, which took over its capability scale; and the exemplar assessment process of 15504-3 became TS 33030. The ISO and IEC catalogue records of each withdrawn 15504 part name the documents that replaced it.

What changed in the thinking

The most important conceptual change is generalisation. Under 15504 the thing being measured was essentially process capability. Under 330xx, capability is only one possible process quality characteristic. The family provides rules (ISO/IEC 33003) for building a measurement framework for any such characteristic, and then supplies one ready-made framework, for capability (ISO/IEC 33020). So far 33020 is the only measurement framework published in the family, which is why "process assessment" and "capability assessment" are often used as if they meant the same thing. It also standardises how ratings are formed from evidence, by defining rating methods and ways of aggregating ratings across process instances, which earlier practice left largely to each assessor.

Purpose and scope today

The family describes three broad uses of assessment results. The first is process improvement: an organisation assesses itself to find strengths and weaknesses and to target improvement where it matters for the business. The second is capability determination: an organisation checks whether its own processes, or those of a supplier or partner, are suitable for a particular requirement, contract or category of work. The third, closely related, is identifying process-related risk and benchmarking performance. All three rely on the same assessment machinery; what differs is who sponsors the assessment and what decision follows.

The scope is deliberately broad. The family applies to organisations of any size and in any domain, covering processes used to develop, maintain and use IT systems and those used to design, transition, deliver and improve services. Nothing in the core documents is tied to a particular industry, life cycle or method. That is why an automotive supplier, a bank's IT department and a small software house can all use the same framework, each with a process model suited to its world.

Lesson 2 – Key concepts and vocabulary

The family is precise about its terms, and most confusion in practice comes from mixing them up. ISO/IEC 33001 is the glossary for the core parts; documents from 33020 upwards define their own extra terms. The definitions below are explained in plain language rather than quoted.

Process – a set of related activities that turns inputs into outcomes, such as "configuration management" or "verification". Assessment always looks at processes, never at individual people.
Process purpose and process outcome – the purpose is the high-level goal of performing a process; outcomes are the observable results that show the purpose has been achieved, such as "baselines are established and controlled".
Process reference model (PRM) – a catalogue of processes, each described by its purpose and outcomes, for a particular domain. It says what a process should achieve, not how. The life cycle processes of ISO/IEC/IEEE 12207 (software) and 15288 (systems) are common sources.
Process measurement framework (PMF) – the scale used to measure a process quality characteristic: the levels, the attributes that make up each level and the rating scale. ISO/IEC 33020 is the framework for capability; ISO/IEC 33003 sets the rules any framework must meet.
Process assessment model (PAM) – the working tool assessors use. It combines processes from one or more reference models with a measurement framework and adds assessment indicators. ISO/IEC 33004 sets the rules a model must meet to be used in a conformant assessment.
Process quality characteristic – a measurable aspect of process quality. Process capability is the best-known one; the family allows others to be defined.
Process capability – the characteristic that expresses how able a process is to meet current or projected business goals consistently, as opposed to succeeding once by luck or heroics.
Process attribute (PA) – a measurable property within a measurement framework, for example "performance management" or "process definition". Attributes are what assessors actually rate.
Capability level – a point on the six-step ordinal scale of ISO/IEC 33020 (0 Incomplete to 5 Innovating). Each level is defined by one or more process attributes.
Process profile – the set of attribute ratings for one assessed process. It is richer than a single level number because it shows partial progress towards the next level.
Organisational unit – the part of an organisation that is assessed, such as one business unit, one site or one product line. Results always belong to a stated organisational unit.
Process instance – one concrete occurrence of a process, for example the configuration management performed in project A. Assessors usually sample several instances and combine their findings.
Assessment indicator – an observable sign that helps an assessor judge achievement. Process performance indicators (such as base practices and information items) relate to the process purpose and outcomes; process capability indicators, called process quality indicators in some models (such as generic practices), relate to the attributes of levels above 1.
Objective evidence – information that can be verified, gathered from interviews, documents, records, tool data and observation. Ratings must be traceable to it.
Organisational process maturity – a rating of how well an organisational unit performs a defined set of processes together, built on process-level results. ISO/IEC 33004 sets requirements for maturity models.
Assessment sponsor and lead assessor – the sponsor is the person or body that commissions the assessment and receives the results; the lead assessor is the competent person responsible for ensuring the assessment meets the requirements of ISO/IEC 33002.
Class of assessment – a level of rigour (Class 1, 2 or 3) defined in ISO/IEC 33002, which determines how much evidence and independence are needed and how far results can be relied on.

How the pieces fit together

A useful way to remember the architecture is this: the reference model says which processes exist and what they should achieve; the measurement framework says how good a process is on some characteristic; the assessment model combines the two and adds indicators that an assessor can look for; and the assessment process of ISO/IEC 33002 says how to gather evidence and rate fairly. Requirements documents (33002, 33003, 33004) do not contain processes or levels themselves; they are rules for the things that do.

Figure 1 – How the core ISO/IEC 330xx documents relate: requirements documents govern frameworks, models and assessments, which together produce process profiles.

Lesson 3 – Structure of the family and the capability framework

Groups of documents

The family is easier to navigate if you group its documents by job rather than by number. The numbers are not random: the low 33000s hold the core concepts and requirements, the 33010s hold guidance, 33020 onward hold measurement frameworks, 33030 holds a documented assessment process, and the 33050s to 33070s hold reference and assessment models for particular domains. Treat this as an orientation aid, and always check the ISO catalogue for the exact document you need.

Group	Example documents	What they give you
Concepts and terminology	ISO/IEC 33001	Overview of the whole family, key terms, how assessment results are used, mapping to ISO/IEC 15504
Requirements	ISO/IEC 33002, 33003, 33004	Rules for performing assessments, for building measurement frameworks, and for building reference, assessment and maturity models
Guidance	ISO/IEC TS 33010, TR 33014, TR 33015, TR 33018	Advice on performing assessments, on using assessment within a process improvement programme, on determining process risk and on assessor competency
Measurement frameworks	ISO/IEC 33020	The capability levels, process attributes, rating scale, rating methods and aggregation rules
Documented assessment process	ISO/IEC TS 33030	An exemplar step-by-step assessment process, with tasks, inputs, outputs and roles, that satisfies 33002
Reference and assessment models	ISO/IEC TS 33052 to TS 33054 (reference models); TS 33060, TS 33061, TS 33062, 33063, TS 33064, TS 33072 to TS 33074 (assessment models)	Ready-to-use models for system life cycle, software life cycle, quantitative higher-level processes, software testing, safety, information security, quality and service management
Technical reports on the capability scale	ISO/IEC TR 33022, TR 33023	Supporting analysis, such as how 12207 processes support the attribute outcomes of 33020 levels 1 to 3

Notice the document types. An International Standard (IS) carries full consensus requirements. A Technical Specification (TS) is published when the committee wants a document available sooner or expects it to evolve; many of the domain models are TS documents. A Technical Report (TR) is informative and contains no requirements. All of them can be used in assessments, but only conformance to the requirements documents makes an assessment "conformant".

Two dimensions: processes and capability

A capability assessment always looks along two dimensions. The process dimension comes from the reference model and lists the processes in scope, each with its purpose and outcomes. The capability dimension comes from the measurement framework and asks, for each process, how well it is performed, managed, standardised, quantitatively controlled and innovated. You can picture a grid: processes down the side, capability attributes across the top, and a rating in each cell. The rows of that grid are the process profiles.

The six capability levels of ISO/IEC 33020

ISO/IEC 33020:2019 defines an ordinal scale of six levels. "Ordinal" means the levels are ordered, but the distance between them is not a fixed amount; Level 4 is not "twice" Level 2. Each level above 0 adds one or more process attributes on top of everything below it.

Level 0 – Incomplete: the process is not implemented or does not achieve its purpose; there is little or no systematic evidence of results.
Level 1 – Performed: the process achieves its purpose. Its single attribute, PA 1.1 Process performance, asks whether the process outcomes are actually produced.
Level 2 – Managed: the performed process is planned, monitored and adjusted, and what it produces is properly established, controlled and maintained. Two attributes: PA 2.1 covers management of the performance (objectives, planning, monitoring and adjusting, responsibilities, resources, interfaces) and PA 2.2 covers management of the work products or information the process produces (requirements for them, their control and their review).
Level 3 – Established: the managed process is now carried out as a tailored instance of an organisation-wide standard process. Its attributes start with PA 3.1 Process definition (a maintained standard process with tailoring guidance, interactions, roles, resources and infrastructure) and PA 3.2 Process deployment (each use is a properly tailored, resourced and staffed defined process, and its data feed back into improving the standard process).
Level 4 – Predictable: the established process operates within defined limits and is managed quantitatively. Its attributes, PA 4.1 Quantitative analysis and PA 4.2 Quantitative control, cover measurement objectives linked to business goals, collecting and analysing data, understanding variation, finding assignable causes and acting on them.
Level 5 – Innovating: the predictable process is continually improved to respond to change. Its attribute or attributes (numbered PA 5.x) cover identifying improvement and innovation opportunities from data and new technologies, and implementing the changes in a controlled way.

A note on names. The attribute identifiers and their general content have been stable since ISO/IEC 15504, but the exact attribute titles have changed between editions. The 2019 edition of 33020 revised the 2015 text, and models derived from it may use their own wording: the Automotive SPICE assessment model, for example, states that it adapts the 33020:2019 framework and renames the process attribute titles. When you read an assessment report, always check which model and which edition of the scale it used, rather than assuming the names you learned elsewhere.

Figure 2 – The six capability levels of ISO/IEC 33020:2019, each adding its process attributes on top of the levels below.

The rating scale

Assessors rate each process attribute on a four-point ordinal scale, and 33020 links each point to a range of percentage achievement. The percentages are a way of calibrating judgement, not a formula you compute from a checklist count.

Rating	Meaning in plain words	Achievement range
N – Not achieved	Little or no evidence that the attribute is achieved	0 % to 15 %
P – Partially achieved	Some approach and some achievement, but results are partly unpredictable	above 15 % to 50 %
L – Largely achieved	A systematic approach and significant achievement, with some weaknesses	above 50 % to 85 %
F – Fully achieved	A complete, systematic approach and full achievement, with no significant weaknesses	above 85 % to 100 %

When more resolution is useful, P and L may each be split into a minus and a plus half (P−, P+, L−, L+), with the boundary at 32.5 % for P and 67.5 % for L. The refinement helps improvement teams see whether they are close to the next step, and it supports aggregation of ratings across several instances.

From attribute ratings to a capability level

A process reaches a given level when the attributes of that level are rated at least Largely achieved and every attribute of all lower levels is rated Fully achieved. In short: "L or F at the level you claim, F everywhere below it". This rule explains why levels cannot be skipped. A team that runs superb quantitative control (Level 4 practices) but has weak control of its work products (PA 2.2 rated P) is still at Level 1 for that process, because the foundation is missing. It also explains why the process profile matters more than the single number: two processes both "at Level 2" can look very different underneath.

Rating methods and aggregation

Because assessors usually examine several instances of each process, ISO/IEC 33020 defines three rating methods. With R1, assessors characterise each process outcome and each attribute outcome for every instance, based on validated data, and then aggregate them. With R2, they characterise each attribute for every instance and aggregate those. With R3, they rate each attribute across the instances directly, without formal aggregation. Aggregation can be vertical (combining outcomes within one attribute), horizontal (combining one item across instances) or two-dimensional (both). The lead assessor chooses the method, which must suit the class of assessment and must be stated in the assessment input and the report.

Lesson 4 – How an assessment works in practice

The five activities of ISO/IEC 33002

ISO/IEC 33002 sets the minimum requirements that make assessment results objective, consistent, repeatable and representative of the processes assessed. It organises the work into five activities.

Plan the assessment. Turn the sponsor's needs into a plan: activities, schedule, people, resources, the processes and instances to sample, how evidence will be collected and how confidentiality will be protected.
Collect the data. Gather objective evidence for each process and attribute in scope, using the indicators of the chosen assessment model. Typical sources are interviews with practitioners and managers, documents and records, tool data such as tickets and version histories, and observation.
Validate the data. Check that evidence is accurate, sufficient and covers the scope. Cross-check interview statements with records, look for gaps, and go back to collect more data where coverage is thin.
Determine the results. Rate the process attributes using the defined scale and rating method, derive capability levels where required, and record the strengths and weaknesses that justify each rating.
Report the assessment. Present the results to the sponsor and keep an assessment record that allows the results to be traced back to the inputs and evidence.

Figure 3 – The assessment activities of ISO/IEC 33002, with the loop back to data collection when validation finds gaps.

The assessment input

Before any evidence is collected, the sponsor and lead assessor agree a written assessment input. It is the contract of the assessment and is often where things go wrong later. It typically records the purpose (improvement, capability determination, risk), the scope (organisational unit, processes, target levels, process instances), the process assessment model and measurement framework, the class of assessment, the rating method, constraints such as availability of staff or exclusions, roles and responsibilities, the identity of the sponsor and lead assessor, confidentiality and ownership of results, and any additional information to be collected. If the scope changes during the work, the input is updated and the change is recorded.

Roles

The sponsor commissions the assessment, approves the input, ensures access to people and evidence, and receives the results.
The lead assessor is accountable for conformance with ISO/IEC 33002, confirms the competence of the team, chooses or approves the rating method and signs off the results.
Assessors collect and validate evidence and take part in rating; they must have adequate competence in the assessment model, the domain and assessment techniques.
Participants are the practitioners and managers who are interviewed or who provide evidence. Their honest cooperation depends on clear confidentiality rules.
A local coordinator often arranges schedules, rooms and document access; the standard does not require this role, but it makes assessments run smoothly.

Artefacts

The key outputs are the assessment report (purpose, scope, constraints, model used, ratings, profiles, findings and, where requested, recommendations) and the assessment record (inputs, evidence references, rating decisions and their justification). A good record allows a second competent assessor to understand how each rating was reached, which is the practical meaning of "repeatable".

Using a documented assessment process

ISO/IEC 33002 states requirements, not a step-by-step method. Organisations and assessor communities therefore write a documented assessment process that meets those requirements. ISO/IEC TS 33030 offers an exemplar for this: it breaks the activities into tasks with inputs, outputs and role assignments, and allows the lead assessor to tailor it as long as the result still conforms to 33002. It covers process assessments of all three classes but is not intended for organisational maturity assessments.

From assessment to improvement

An assessment that ends with a report on a shelf has wasted everyone's time. The technical report ISO/IEC TR 33014 provides guidance on embedding assessment in improvement. In practice an improvement cycle looks like this: start from business goals (for example, fewer late releases or fewer escaped defects), choose the processes that most affect those goals, assess them, agree a small number of prioritised actions, implement them as projects with owners and measures, and re-assess to confirm the effect. The target level should follow from business need; there is no rule that every process must reach Level 3 or higher.

Lesson 5 – Assessment, certification and compliance

Conformant assessments

An assessment can claim conformance to the family when it is performed according to ISO/IEC 33002, uses a process assessment model that meets ISO/IEC 33004 and a measurement framework that meets ISO/IEC 33003, and is led by a competent lead assessor. A conformant assessment is not necessarily an external one. Self-assessment is explicitly supported, and many organisations run regular internal assessments for improvement, keeping more rigorous, independent assessments for situations where others will rely on the results.

Three classes of assessment

ISO/IEC 33002 defines three classes so that rigour can match the purpose. Each class has its own requirements for planning, data collection and validation, and determining and reporting results.

Class 1 is the most rigorous. It needs the broadest coverage of process instances and evidence and the greatest independence of the team, and its results are intended to be reliable enough for comparison between organisations, for example in supplier selection or benchmarking.
Class 2 is moderately rigorous. Its results give a dependable picture of the organisational unit, often used to set an improvement baseline or to check progress, but are less suited to comparing organisations.
Class 3 is the lightest. It gives a quick indication of strengths and weaknesses, for example to decide where to focus or to prepare for a more formal assessment, and its results should not be used to compare organisations.

ISO/IEC 33002 also deals with the independence of the assessment team from the organisational unit being assessed. Independence matters most when results are used by someone outside the unit, such as a customer, because people naturally rate their own work more generously.

Is there an "ISO 330xx certificate"?

No. ISO and IEC publish the standards but do not assess or certify anyone, and the family does not define a certification scheme for organisations in the way ISO 9001 or ISO/IEC 27001 are used with accredited certification bodies. The outcome of an assessment is a set of ratings for a defined scope at a point in time. A capability level says that the sampled instances showed the process to be capable of performing at that level; it does not guarantee that the organisation will always do so, which fits the way 33020 describes capability as the ability to meet business goals consistently. General questions about applying conformity assessment to process assessment and maturity are addressed in a separate standard, ISO/IEC 29169.

Competence of assessors is required by ISO/IEC 33002, but the standard does not run a register of assessors. Training and certification of assessors are provided by independent schemes, mostly around particular models. The best-known example is the intacs scheme used for Automotive SPICE and related models. When someone says "we are certified Level 3", ask what they actually mean: which model, which processes, which organisational unit, which class, which lead assessor, when, and how many instances were sampled.

Reading someone else's results

When you receive a supplier's assessment report, look for the assessment input first. A strong result for three projects in one development centre says little about another site, or about processes that were not in scope. Check the date, because processes can decay after reorganisations or staff turnover. Check the class and independence, because a Class 3 self-assessment is a useful conversation starter but not evidence for a contract decision. And read the profiles, not just the levels: a process at Level 2 with PA 3.1 rated L is in a very different position from one at Level 2 with all Level 3 attributes rated N.

Maturity versus capability

The family distinguishes process capability (per process) from organisational process maturity (for an organisational unit across a defined set of processes). A maturity model built under ISO/IEC 33004 states which processes, at which capability levels, are needed for each maturity level. Capability results are the building blocks; maturity is a summary built on top of them. Many practical assessments, including most supplier assessments in the automotive sector, report capability per process and never claim a maturity level.

Lesson 6 – Worked example

The situation

Kestrel Systems (a fictional company) develops embedded and back-office software for logistics customers, with about 180 staff in two development centres. A large customer has started asking suppliers for evidence that key engineering processes are at capability level 2, and internally the CTO is frustrated by late releases and frequent "lost" configurations at delivery time. The CTO decides to sponsor an assessment for two purposes: improvement first, and preparation for future customer capability determination.

Step 1 – Define the assessment input

The CTO engages an external lead assessor with recognised training in the chosen model. Together they write the assessment input. The organisational unit is the main development centre. The model is ISO/IEC TS 33061 (software life cycle processes, using ISO/IEC/IEEE 12207 as the reference model) with the capability framework of ISO/IEC 33020. Five processes are in scope: project planning, project assessment and control, configuration management, quality assurance and software requirements definition. The target is level 2, but attributes up to level 3 will be rated to show the path ahead. Because results will guide internal investment and might later be shown to customers, they choose a Class 2 assessment, three project instances per process, and rating method R2. Confidentiality rules say that no finding will be attributed to an individual.

Step 2 – Plan, collect and validate

The team of three assessors (the external lead assessor, one external assessor and one trained internal quality engineer from the other centre) plans two weeks of work. They hold a short kickoff to explain purpose and confidentiality, then interview project managers, developers, testers and the release manager for each sampled project. They review project plans, status reports, risk lists, the configuration management plan, baseline records in the version control system, quality assurance reports and requirements specifications. Where an interviewee says "we always tag the release baseline", the assessors check the repository and find tags for two projects but not for the third. That discrepancy is recorded and followed up rather than glossed over.

Step 3 – Determine the results

For each attribute and each project, the assessors characterise achievement, then aggregate across the three projects as R2 requires. The resulting profile is shown below.

Process	PA 1.1	PA 2.1	PA 2.2	Level 3 attributes	Level
Project planning	F	L	P	P or N	1
Project assessment and control	F	L	L	P or N	2
Configuration management	L	P	P	all N	1
Quality assurance	F	F	F	all L	3
Software requirements definition	F	L	L	all N	2

Walk through the derivation. Project planning has PA 1.1 fully achieved, but PA 2.2 is only partially achieved because plans are kept as uncontrolled spreadsheets with no versioning or approval; Level 2 needs both Level 2 attributes at L or F, so the process stays at Level 1. Configuration management performs its purpose largely (PA 1.1 rated L), which is enough for Level 1 but not a foundation for Level 2, where PA 1.1 must be F. Quality assurance, run by a small central team with a defined, deployed and audited procedure, reaches Level 3: all Level 1 and 2 attributes are F and every Level 3 attribute is L. Project assessment and control and requirements definition reach Level 2.

Figure 4 – Deriving a capability level from a process profile: each level needs its own attributes at L or F and all lower attributes at F.

Step 4 – Report and decide

The report explains each rating with specific strengths and weaknesses, for example: "Baselines for releases are not consistently identified; in one of three projects the delivered configuration could not be reproduced from version control." The CTO does not try to "fix the levels". Instead, she links findings to the business problems. Late releases connect to weak planning control and uncontrolled plans; "lost" configurations connect directly to configuration management. She sponsors three improvement actions: a controlled planning template with versioning and approval in the project tool; a mandatory release baseline with automated tagging in the build pipeline; and a short configuration management standard with training for all project leads. Each action has an owner, a deadline and a measure, such as "percentage of releases reproducible from version control".

Step 5 – Re-assess and use the results externally

Nine months later, a smaller Class 3 assessment shows configuration management at PA 1.1 F and PA 2.1 and PA 2.2 at L, and project planning with PA 2.2 at L. The CTO then commissions a Class 2 assessment with the same model and scope to confirm Level 2 for all five processes before sharing results with the customer, attaching the assessment input so the customer can see exactly what was assessed. The customer, in turn, can decide whether it needs its own independent assessment for a contract decision. Kestrel never claims to be "330xx certified"; it reports what was assessed, how, and with what result.

What the example teaches

The example shows the full chain of the family in action: a reference model supplied the processes, 33020 supplied the scale, the assessment model supplied indicators, 33002 shaped the activities and rigour, and the results fed both improvement and a later capability determination. It also shows that the most useful output was not the level numbers but the specific, evidence-based weaknesses that pointed to concrete improvements.

Lesson 7 – Relationship to other standards and frameworks

The 330xx family is infrastructure: it defines how to build and use assessment models rather than prescribing a particular way of working. That is why it often sits behind other frameworks rather than competing with them.

Standard or framework	What it is	Relationship to ISO/IEC 330xx
ISO/IEC 15504 (SPICE)	The earlier multi-part process assessment standard	Direct predecessor; its parts were progressively replaced by 330xx documents between 2015 and 2025, as the catalogue records of the withdrawn parts show. Many people still say "SPICE" for both.
Automotive SPICE	An industry process reference and assessment model for automotive software and systems, maintained by the VDA Quality Management Center	Built to the 330xx requirements: its assessment model follows ISO/IEC 33004 and its measurement framework is an adaptation of ISO/IEC 33020; assessments follow ISO/IEC 33002 with extra industry rules.
CMMI	A proprietary capability and maturity model owned by ISACA	Shares the idea of levels and evidence-based appraisal but uses its own architecture, appraisal method and rating rules; it is not a 330xx-conformant model by default.
ISO/IEC/IEEE 12207 and 15288	Life cycle process standards for software and for systems	Common sources of process reference models; ISO/IEC TS 33061 and TS 33060 build assessment models on them, and TR 33022 analyses how 12207 processes support the 33020 attributes.
ISO 9001	Requirements for a quality management system, used for third-party certification	Different purpose (certifiable management system requirements). The family complements it with a process reference model for quality management (TS 33053) and a matching capability assessment model (TS 33073), so an organisation can see how capable its quality management processes are.
ISO/IEC 27001 and service management standards	Management system standards for information security and IT services	Process models in the family, such as ISO/IEC TS 33072 for information security management and TS 33074 for service management, let organisations assess process capability in these areas alongside certification.

Choosing what to use

If you are in automotive, you will usually meet the family through Automotive SPICE, and your customers will specify that model. If you build general software or systems and want an international, vendor-neutral basis, the TS 33061 or TS 33060 models with 33020 are natural choices. If your aim is a certificate for a management system, ISO 9001 or ISO/IEC 27001 is the right tool, and a 330xx assessment can complement it by showing how capable individual processes are. And if you need a model for a domain not yet covered, ISO/IEC 33004 and 33003 tell you how to build one that others can trust.

Common pitfalls and best practices

Common pitfalls

Treating the target level as the goal, so teams produce documents to satisfy indicators instead of improving results that matter to the business.
Writing a vague assessment input, which leads to arguments later about what was in scope, what the results mean and who owns them.
Sampling only the best project or the most willing team, so the results are not representative of the organisational unit.
Rating from interviews alone without cross-checking records and tool data, which makes ratings optimistic and not repeatable.
Reporting only level numbers and hiding the attribute profile, so readers cannot see partial achievement or where the real gaps are.
Calling an assessment result a "certificate" or reusing an old result for a different site, scope or time.
Using a Class 3 self-assessment to support an external contract decision that needs the rigour and independence of Class 1 or 2.

Best practices

Start from business goals and choose processes and target levels that address them; not every process needs the same level.
Agree and record the assessment input before collecting any evidence, including model, class, rating method, scope and confidentiality.
Use a documented assessment process (for example based on ISO/IEC TS 33030) and a trained, competent lead assessor.
Triangulate evidence: interviews, documents, records and tool data should support each rating.
Report strengths and weaknesses with the ratings, and keep an assessment record that lets another assessor follow every decision.
Turn findings into a small number of owned, measurable improvement actions, then re-assess to confirm the effect.
When relying on a supplier's results, read the assessment input, class, date and profile before trusting the headline level.

Summary and key takeaways

ISO/IEC 330xx is a family, not a single standard: concepts (33001), requirements (33002 to 33004), guidance (33010 to 33018), the capability measurement framework (33020) and domain models (33052 onward).
It replaced and generalised ISO/IEC 15504, so any process quality characteristic can be measured; capability is the most widely used.
A reference model says what processes should achieve, a measurement framework says how to measure them, and an assessment model combines the two with indicators.
ISO/IEC 33020:2019 defines six capability levels from Incomplete to Innovating, the process attributes that define each level and the N, P, L, F rating scale.
A level is reached when its attributes are at least Largely achieved and every lower attribute is Fully achieved, so levels cannot be skipped.
ISO/IEC 33002 defines five assessment activities, the roles of sponsor and lead assessor, and three classes of rigour.
Results are ratings for a defined scope at a point in time, not a certificate; read the assessment input before relying on them.
Industry models such as Automotive SPICE are built on the family, which is why understanding 330xx helps you understand them.

Reflection questions

Think of one process in your own organisation. Which of its outcomes could you prove with records today, and which only with people's word? What capability level would you expect an assessor to give it, and why?
Your organisation wants to show a key customer that its delivery processes are capable. Which class of assessment, which processes and which model would you propose, and what would you put in the assessment input?
A colleague argues that the fastest way to "get Level 3" is to write a standard process document for every process. Using the attributes of Levels 2 and 3, explain what else would be needed and what risks this shortcut carries.
A supplier sends you a one-page summary saying "SPICE Level 2 achieved". List the questions you would ask before using this in a sourcing decision, and explain why each matters.
Where would quantitative management (Level 4) genuinely add value in your context, and where would it be wasted effort? What data would you need first?