ISO/IEC/IEEE 12207: ISO/IEC/IEEE 12207 – Tutorial (about 60 minutes)

ISO/IEC/IEEE 12207 is the international standard that describes the processes needed across the whole life of a software system: buying it or supplying it, defining and building it, running and maintaining it, and finally retiring it. Acquirers, suppliers, engineering managers, process owners, quality and safety people and assessors use it as a shared vocabulary and a common process framework, so that different organisations mean the same thing when they talk about "requirements definition" or "configuration management". After this tutorial you will be able to explain how the standard is organised, read and apply a process description, tailor the standard to a real project, and judge what a claim of conformance actually means.

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

Course overview

Edition and status: the current edition is ISO/IEC/IEEE 12207:2026, Systems and software engineering – Software life cycle processes, published jointly by ISO, IEC and IEEE. It was prepared by ISO/IEC JTC 1/SC 7 (Software and systems engineering) together with the IEEE Computer Society's Software and Systems Engineering Standards Committee. The IEEE SA Standards Board approved it on 2026-02-12, IEEE lists it as published on 2026-04-15 and active, and the ISO catalogue lists it as the second edition dated 2026-04. It cancels and replaces ISO/IEC/IEEE 12207:2017, which is now withdrawn. ("Second edition" counts only the joint ISO/IEC/IEEE documents; earlier ISO/IEC editions appeared in 1995 and 2008.) Verified 2026-10-29 against the IEEE SA entry for 12207-2026 and the official ISO/IEC/IEEE preview of the document. Much of the published training and guidance material still describes the 2017 edition; the 30-process structure taught here is the same in both, but check exact process names and clause numbers in the copy you hold.

Who it is for: software and systems engineers, engineering and project managers, process and quality leads, people in safety-critical domains (automotive, rail, aerospace, medical) who meet 12207 as the background to their domain standards, procurement staff who write software contracts, and anyone preparing for a process assessment.

Prerequisites: none. A rough idea of how software is built and run (requirements, design, code, test, release, operations) is enough; every term is explained the first time it appears.

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 reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why ISO/IEC/IEEE 12207 exists, what it covers and what it deliberately leaves out.
You will be able to use its core vocabulary correctly: system-of-interest, enabling system, life cycle model, stage, process, outcome, activity, task, information item and tailoring.
You will be able to name the four process groups and place each of the 30 processes in the right group.
You will be able to read a process description and turn it into practical project work, including in agile and DevOps settings.
You will be able to tailor the standard with recorded reasons and choose between full conformance to outcomes, full conformance to tasks and tailored conformance.
You will be able to explain how 12207 is used in contracts and process assessments, and why there is no certificate for the standard itself.
You will be able to position 12207 against ISO/IEC/IEEE 15288, the ISO/IEC 330xx assessment family, ISO 9001 and domain safety standards.

Lesson 1 – Origins, purpose and scope

The problem it solves

Imagine a city transport authority buying a new ticketing system. The authority writes "the supplier shall perform adequate testing and configuration control". The supplier reads "adequate" as "whatever our team usually does". Six months later, an audit finds no record of which version of the code is running on the ticket machines and no evidence that anyone checked the software against what passengers and operators actually needed. Each side thinks the other broke the agreement. The root problem is not bad people; it is that the two organisations never shared a precise picture of which life cycle work had to happen, what each piece of work was meant to achieve, and how anyone would know it had been achieved.

ISO/IEC/IEEE 12207 was created to give the software industry exactly that shared picture. It is a reference set of processes, each with a stated purpose and a list of results it should produce, that any organisation can adopt, adapt and point to. It does not tell you which programming language, method or tool to use. It tells you which kinds of work a responsible software life cycle needs and what each kind of work is for.

A short history

The first edition, ISO/IEC 12207:1995, organised software work into primary processes (such as acquisition, supply, development, operation and maintenance), supporting processes and organisational processes. It was amended twice and widely adopted; in the United States, IEEE and the Electronic Industries Alliance published their own adaptation, which replaced the military standard MIL-STD-498 for defence software in 1998. The 2008 edition, published by ISO/IEC and IEEE in coordinated form, aligned the software standard with the systems engineering standard ISO/IEC 15288 and carried two families of processes: system context processes and software-specific processes, 43 in total.

The 2017 edition, the first issued as a single joint ISO/IEC/IEEE document, took a decisive step: it adopted the same process model as ISO/IEC/IEEE 15288:2015, the system life cycle standard. The separate software-specific process set disappeared, and both standards now share the same 30 processes in four groups, with the same purposes and outcomes. What differs is the detail of the activities and tasks, which in 12207 are written from a software engineering point of view.

The 2026 edition keeps that architecture and brings 12207 into line with ISO/IEC/IEEE 15288:2023. According to its foreword, the main changes are clarified and modernised technical processes (including business or mission analysis, system architecture definition, implementation, integration, operation and maintenance), improved risk management and configuration management processes, a more precise treatment of key concepts such as iteration, recursion, systems of systems and quality characteristics, new material on concept and system definition, more content on agile methods and process application, and a revised annex on model-based systems and software engineering.

Scope in plain words

The standard covers the full life of software systems, products and services: conception, development, operation, support and retirement, plus the acquisition and supply relationships around them, whether the work is done inside one organisation or across several. It applies to one-off bespoke systems, mass-market products and configurable platforms; to stand-alone software and to software embedded in larger systems; and to the software part of firmware. It includes just enough system definition to give software its context, because software never runs alone: it always needs hardware, data, people and procedures around it.

Three things are explicitly outside its scope. First, it does not prescribe a life cycle model, method or technique: waterfall, incremental, spiral, Scrum and continuous delivery are all equally acceptable ways to arrange its processes. Second, it does not define the format or detailed content of documents; that job belongs to a companion standard, ISO/IEC/IEEE 15289. Third, it cannot replace engineering judgement about how much rigour a given system needs. The standard is a menu and a common language, not a recipe.

Four ways the standard is used

The standard itself describes several modes of use. An organisation can use it to set up a defined environment of processes, supported by methods, tools and trained people, that all its projects draw on. A project can use it to select and arrange the processes it needs from that environment. An acquirer and a supplier can use it to agree, in a contract or a lighter-weight agreement, which processes and activities will be performed. And process assessors can use it as a process reference model when they assess an organisation's capability as a basis for improvement. Keep these four modes in mind; most confusion about 12207 comes from mixing them up.

Lesson 2 – Key concepts and vocabulary

12207 is precise about words, and it shares most of its terminology with the wider systems and software engineering vocabulary maintained as ISO/IEC/IEEE 24765. The definitions below are explained in our own words.

Software system – a system in which software is the main element of interest, together with the hardware, data, people, procedures and facilities it needs to deliver its service.
System-of-interest (SoI) – the system whose life cycle you are currently managing. A payment service might be the SoI for one team and just one element of a larger banking platform for another.
System element – a part of a system that can be treated as a unit: a microservice, a library, a database, a hardware board, an operating procedure.
Enabling system – a system that supports the SoI during part of its life without being part of it, such as a build pipeline, a test laboratory, a simulator or a deployment platform. Enabling systems have their own life cycles.
Interoperating system – a separate system that exchanges information or services with the SoI while it operates, such as a bank's card network for a ticketing system.
Stakeholder – any person or organisation with a right, share, claim or interest in the system: users, operators, maintainers, acquirers, regulators, the public.
Acquirer and supplier – the two parties to an agreement: the acquirer obtains a product or service, the supplier provides it. The same organisation can play both roles in a chain, for example buying components while supplying a finished system.
Life cycle – the evolution of a system from conception to retirement.
Stage – a period within the life cycle, such as concept, development or retirement; moving from one stage to the next is normally controlled by a decision point.
Life cycle model – the framework of stages and processes an organisation or project chooses, for example a staged plan-driven model or an incremental agile model.
Process – a set of related activities that turns inputs into outputs in order to achieve a stated purpose.
Purpose – the high-level goal of a process: why it exists.
Outcome – an observable result of performing the process successfully; for risk management, for example, that risks have been identified and analysed.
Activity and task – an activity is a coherent group of tasks within a process; a task is a specific action that contributes to an outcome. In 12207 tasks are written as requirements, recommendations or permitted actions.
Information item – a separately identifiable body of information produced or used by a process, such as a plan, a requirements specification or a test report. It does not have to be a traditional document; a well-managed backlog or a repository can hold it.
Tailoring – adapting the processes, activities and tasks of the standard to a particular situation, with the decisions and their reasons recorded.
Baseline – a formally agreed version of a configuration item that serves as the reference for further work and can only be changed through a controlled procedure.
Verification and validation – verification gives objective evidence that something meets its specified requirements ("did we build it right?"); validation gives objective evidence that it fulfils its intended use in its intended environment ("did we build the right thing?").
Process reference model (PRM) – a set of process descriptions limited to purpose and outcomes, used as the yardstick in process assessment.

Iteration, recursion and concurrency

Three ideas make the standard compatible with modern ways of working. Iteration means repeating a process, or a set of processes, as understanding improves: you revisit requirements after a prototype shows users what they really need. Recursion means applying the same processes again at each level of the system structure: the platform team applies requirements definition, architecture and verification to the whole system, and each component team applies the same processes to its own component. Concurrency means processes run at the same time rather than strictly one after another: risk management, configuration management and measurement run throughout, and in an agile team design, implementation and verification happen inside the same sprint. A common beginner mistake is to read the list of technical processes as a sequence of phases; the standard explicitly does not mean that.

Lesson 3 – Structure of the standard

How the document is organised

The 2026 edition follows the usual pattern for this family of standards. Clause 1 sets the scope; clause 2 notes that there are no normative references; clause 3 holds the terms, definitions and abbreviations; clause 4 defines what conformance means; clause 5 explains the key concepts (software systems and their structure, organisation and project concepts, life cycle concepts, process concepts, the process groups, how processes are applied, and the process reference model); and clause 6 contains the detailed process descriptions. Five annexes follow: a normative annex describing the tailoring process (Annex A), and informative annexes giving examples of information items produced by each process (Annex B), the process reference model for assessment purposes (Annex C), guidance on model-based systems and software engineering (Annex D), and a short treatment of assurance and assurance cases (Annex E).

The four process groups

Clause 6 arranges the 30 processes into four groups. Learning which process sits where is the single most useful thing you can do to become fluent with the standard.

Agreement processes (2). These govern the relationship between two parties. The acquisition process covers obtaining a product or service: preparing a request, selecting a supplier, establishing and managing the agreement, and accepting what is delivered. The supply process is its mirror image: responding to a request, agreeing terms, executing the agreement and delivering. Agreements can be formal contracts between companies or informal arrangements between two departments of the same company.

Organizational project-enabling processes (6). These give projects what they need to succeed and are usually owned at the organisation level. Life cycle model management defines and improves the organisation's processes and life cycle models. Infrastructure management provides facilities, tools and platforms. Portfolio management starts, sustains or stops projects according to strategy and resources. Human resource management supplies people with the right skills. Quality management makes sure products, services and processes meet the organisation's quality objectives and that customers are satisfied. Knowledge management captures and reuses knowledge, skills and assets across projects.

Technical management processes (8). These manage the project and its information. Project planning produces and coordinates workable plans. Project assessment and control checks progress against plans and steers corrective action. Decision management gives a structured basis for choosing between alternatives. Risk management identifies, analyses, treats and monitors risks continuously. Configuration management controls system elements and their configurations over the life cycle. Information management makes relevant, timely, complete and valid information available to the right stakeholders. Measurement collects and analyses data to support decisions. Quality assurance gives confidence, at project level, that the organisation's quality management is applied effectively.

Technical processes (14). These do the engineering. Business or mission analysis defines the problem or opportunity and the solution space. Stakeholder needs and requirements definition captures what stakeholders need and turns those needs into stakeholder requirements. System requirements definition translates them into a technical view of the required solution. System architecture definition produces alternative architectures and selects one. Design definition provides enough detail about each element to implement it. System analysis provides a rigorous data basis for technical understanding and decisions. Implementation realises an element, for software usually by coding or configuring it. Integration combines elements into a working whole. Verification shows that requirements are fulfilled. Transition moves the system into its operational environment. Validation shows that the system meets its intended use. Operation uses the system to deliver its service. Maintenance sustains it, correcting faults and adapting it. Disposal ends its existence in a controlled way, including data retention or destruction.

Two naming notes help when you read older material. The 2017 edition called two of the technical processes "System/software requirements definition" and "Architecture definition"; the 2026 table of contents uses "System requirements definition" and "System architecture definition", matching the systems standard. And "QA" in Figure 1 is the project-level quality assurance process, which is distinct from the organisation-level quality management process.

Anatomy of a process description

Every process in clause 6 is described in the same layered way, following the rules for process descriptions in ISO/IEC/IEEE 24774. Understanding this layering is what lets you apply the standard flexibly without losing the point.

Figure 2 – How a 12207 process is described, and which layers form the process reference model used in assessment.

The purpose is one or two sentences stating why the process exists. The outcomes are a short list of results you could observe if the process were working: for risk management, for example, that risks are identified, analysed and treated and that the risk situation is kept visible. The activities group related work, and the tasks inside them describe specific actions. The purpose and outcomes together form the process reference model; activities and tasks add the "how" at a level that is still independent of any particular method or tool. The information items the process produces are listed as examples in Annex B, with their content left to ISO/IEC/IEEE 15289.

Notice the direction of the arrows. The outcomes are the stable core; the tasks are one well-tested way to reach them. That is why the standard offers two kinds of full conformance, explained in Lesson 5, and why an agile team can satisfy the outcomes of verification through automated test suites and code review rather than through a heavyweight test phase.

Lesson 4 – How it works in practice

From a menu to a life cycle model

The processes in 12207 are not a project plan. To use them, an organisation first builds one or more life cycle models: arrangements of stages, decision points and processes that suit its products. A widely used generic set of stages, described in the companion guidance ISO/IEC/IEEE 24748-1, is concept, development, production, utilisation, support and retirement. For software, "production" is usually trivial, because copies cost almost nothing, so the emphasis falls on development, utilisation and support. The organisation then decides which processes are active in each stage and at what depth.

Figure 3 – Processes mapped onto generic life cycle stages, with the feedback loops that make the life cycle iterative rather than a one-way sequence.

Figure 3 is deliberately not a waterfall. The dashed arrows show iteration: verification and validation findings flow back into development, and operational experience flows back into new concept and development work for the next increment. The "Throughout" box shows concurrency: agreement, technical management, configuration, risk and quality assurance processes run alongside every stage. In a continuous delivery setting, the whole loop from a small change request to transition into production may happen many times a day; the standard still applies, but each process is performed in small, automated slices.

Roles and responsibilities

12207 assigns no job titles. It speaks of parties performing processes: the acquirer performs acquisition, the supplier performs supply, the organisation performs the enabling processes and the project performs technical management and technical processes. In practice you map these to your own roles. A product owner may perform much of stakeholder needs definition; a platform team may own infrastructure management; a quality function may perform quality assurance; a site reliability team may perform operation and part of maintenance. Writing that mapping down, usually as a simple matrix of processes against roles, is one of the most valuable early steps, because it exposes processes nobody owns.

Implementation steps for an organisation

Clarify the goal. Are you adopting 12207 to win contracts that cite it, to prepare for a process assessment, to support a safety case, or simply to reduce chaos? The goal decides how deep and how formal the adoption needs to be.
Map what already exists. Take the 30 processes and, for each, record how your organisation already does that work, who owns it and what evidence it leaves. Most organisations find they perform most processes informally.
Identify gaps against outcomes. For each process, compare your practice with the outcomes. Gaps against outcomes matter more than gaps against individual tasks.
Define the organisational process set. Through life cycle model management, write lightweight descriptions of how each process is done here, linked to templates, tool configurations and checklists. Keep them short and usable.
Provide enabling support. Set up infrastructure (repositories, pipelines, issue trackers), training and knowledge bases so projects can follow the defined processes without heroics.
Tailor per project. Each project selects and adapts the processes, recording the decisions and reasons (Lesson 5 describes the tailoring process).
Measure and improve. Use measurement, quality assurance and periodic assessments to see whether processes achieve their outcomes, and feed lessons back through life cycle model management.

Information items without paperwork

A frequent fear is that 12207 means writing dozens of documents. It does not. The standard identifies information items, and Annex B lists examples per process, but it leaves name, format and medium open. A requirements specification can be a set of linked backlog items with acceptance criteria; a configuration status report can be generated from the version control system; a verification report can be the archived output of a pipeline run with its test results. What matters is that the information exists, is controlled, is available to the people who need it, and can be produced as evidence. Information management and configuration management are the two processes that make this work.

12207 in agile and DevOps teams

The 2026 edition expands its explanation of agile approaches, and the joint standards family also includes dedicated documents such as ISO/IEC/IEEE 32675:2022 on DevOps. The practical mapping is straightforward once you think in outcomes. Sprint planning and backlog refinement perform parts of project planning, decision management and stakeholder needs definition. Definition-of-done criteria and automated pipelines perform much of implementation, integration and verification. Sprint reviews with real users contribute to validation. Release automation performs transition. Monitoring, incident handling and on-call rotations perform operation and maintenance. Retrospectives feed knowledge management and process improvement. The standard asks you to be able to show that the outcomes are achieved, not that you held a particular meeting.

Lesson 5 – Assessment, certification and compliance

What "conformance" means

Clause 4 of the standard defines how an organisation or project can claim conformance. The claim always applies to a declared set of processes: you name which of the 30 processes you claim, and the claim is judged only against those. Three forms of claim are possible.

Full conformance to outcomes – every outcome of each declared process is achieved. How you achieve it is up to you. This form suits organisations using their own methods, agile teams, and situations where innovation in practice is welcome.
Full conformance to tasks – every requirement in the activities and tasks of each declared process is met. This form is stricter and more prescriptive, and it tends to appear where an acquirer wants to know exactly what work will be performed, as in some government or defence contracts.
Tailored conformance – the standard has been adapted through the tailoring process in Annex A, and the claim states what was selected, modified or left out. Tailored conformance is honest and common; it is not a "lesser" claim as long as the tailoring is justified and recorded.

The tailoring process

Annex A is the only normative annex, which tells you how seriously the standard takes tailoring. In outline, the tailoring process asks you to identify and record the circumstances that influence tailoring (such as safety or security criticality, contract terms, regulation, size, novelty and team experience), to consider any life cycle structures mandated by domain standards or regulators, to get input from the parties affected, to make and record the tailoring decisions with their reasons, and to select the processes that need tailoring. The result is a tailoring record that someone else can review.

Figure 4 – The tailoring flow, from the circumstances of a project to the kind of conformance claim it can support.

Is there a 12207 certificate?

No. ISO, IEC and IEEE do not certify anyone, and there is no accredited certification scheme in which a certification body issues "ISO/IEC/IEEE 12207 certified" certificates comparable to ISO 9001 or ISO/IEC 27001 management system certificates. 12207 is a process framework, not a management system requirements standard. Be sceptical of any offer to "certify" an organisation to 12207 in the accredited sense. What does exist is evidence of conformance and capability, gathered in several ways.

First-party (self) declaration – the organisation states which processes it conforms to and in which form, supported by its own internal audits and records.
Second-party evaluation – an acquirer audits or assesses its supplier against the processes named in the agreement.
Third-party process assessment – an independent assessor rates process capability using the ISO/IEC 330xx family. ISO/IEC 33002 sets the requirements for performing an assessment, ISO/IEC 33020 provides a measurement framework with capability levels from 0 (incomplete) through 1 (performed), 2 (managed), 3 (established) and 4 (predictable) to 5 (innovating), and ISO/IEC TS 33061 provides a process assessment model built on the 12207 process reference model.
Related certifications – an organisation can hold ISO 9001 certification for its quality management system (with ISO/IEC/IEEE 90003 as guidance for software), or undergo appraisals or assessments against models such as CMMI or Automotive SPICE. These are separate schemes, but much of the evidence overlaps.

How a process assessment works

In a process assessment, the assessor first agrees the scope: which processes, which organisational units, which projects and which target capability levels. Evidence is then collected from interviews, documents, tool data and observation. For each process, the assessor rates whether the process achieves its outcomes (level 1, "performed") and then whether higher-level attributes are in place, such as planned and monitored performance and controlled work products (level 2), or a standard process that projects tailor (level 3). The result is a capability profile, not a pass or fail: for example, "project planning at level 2, configuration management at level 3, measurement at level 1". The value lies in the gaps the profile reveals, which feed an improvement plan.

Compliance in regulated and safety-critical domains

In automotive, rail, aerospace, medical and industrial domains, regulators and customers usually require compliance with a domain standard rather than with 12207 directly. Those domain standards, however, are built on the same life cycle ideas, and 12207 often provides the vocabulary and the processes that sit underneath them. An automotive supplier assessed with Automotive SPICE, or building an ISO 26262 safety case, will find that its configuration management, verification and supplier management practices map closely onto 12207 processes. Using 12207 as the organisational backbone and adding domain-specific requirements on top is a common and efficient pattern.

Lesson 6 – Worked example

The situation

Brightway Transit, a regional public transport authority, wants a new passenger information and fleet telematics system: software on buses that reports location and occupancy, a cloud back end that predicts arrival times, a mobile app and roadside displays. It will buy the system rather than build it. Northline Software, a 120-person company, wins the tender. The tender asked suppliers to describe their life cycle processes with reference to ISO/IEC/IEEE 12207 and to accept a capability assessment of selected processes before the second release.

Step 1 – Agreement

Brightway runs the acquisition process: it prepares a request describing needs, constraints (accessibility, data protection, integration with the existing ticketing system) and the processes it wants to see evidence of. Northline runs the supply process: it responds, negotiates and signs. Rather than demand full conformance to tasks on all 30 processes, the two parties agree a declared set of processes and a tailored conformance claim based on outcomes, with full conformance to tasks only for configuration management and verification, where Brightway has been burned before. The agreement also sets acceptance criteria and how changes to requirements will be handled.

Step 2 – Organisational foundations

Northline's process group (life cycle model management) already has a light process handbook mapped to the 30 processes, with an incremental agile life cycle model for product work. Infrastructure management provides the repositories, build pipeline, test environments and a bus-hardware test bench (an enabling system). Human resource management identifies a gap: nobody has embedded Linux experience on the vehicle units, so the company hires one engineer and trains two more. Portfolio management confirms the project fits strategy and capacity, and quality management sets the quality objectives that the project's quality assurance will check.

Step 3 – Tailoring and planning

The project manager and technical lead run the tailoring process. Circumstances recorded: public-facing service, personal data in the app, a hard integration deadline with the ticketing system, moderate safety relevance (the displays are not safety functions, but wrong arrival times on a busy road can lead people to cross dangerously, so the team treats display accuracy as a quality priority). Decisions recorded with reasons: system analysis is done lightly except for the arrival-prediction model; disposal is planned now for the old display controllers being replaced; measurement focuses on prediction accuracy, deployment frequency and defect escape rate. The project plan, the risk register and the configuration management plan are produced as living information items in the team's tools.

Step 4 – Technical work in increments

Business or mission analysis and stakeholder needs definition happen in workshops with drivers, dispatchers, passengers with visual impairments and the ticketing team. Stakeholder requirements become system requirements in the backlog, each with acceptance criteria and traceability links. The system architecture definition process compares two architectures (on-bus prediction versus cloud prediction) using decision management, and the team records why it chose cloud prediction with an on-bus fallback. Each two-week increment then applies design definition, implementation, integration and verification recursively: the vehicle-unit team and the cloud team each run them for their own elements, and a system integration team runs them for the whole. Verification is largely automated in the pipeline, plus reviews and hardware-in-the-loop tests on the bench.

Step 5 – Management throughout

Risk management runs every sprint: the top risk is the ticketing interface, so the team builds a stub of it early and agrees an interface baseline with the ticketing vendor. Configuration management baselines every release and records exactly which software version runs on which bus; this answers Brightway's original pain point. Quality assurance, performed by a Northline quality engineer outside the delivery team, samples pipeline logs, checks that tailoring decisions are followed and reports deviations. Project assessment and control compares velocity and measurement data with the plan and triggers a re-plan when the ticketing vendor slips.

Step 6 – Transition, validation and operation

Transition starts with ten buses on one route. Validation happens in real service: dispatchers and passengers use the system, and their feedback is compared with the stakeholder needs. One finding is that the audio announcements in the app are too fast for some users, which goes back into the backlog as a needs change rather than a defect. After roll-out, operation is performed by Brightway's control centre with Northline providing maintenance under a support agreement. Maintenance requests flow back into new increments, closing the loop shown in Figure 3. The old display controllers go through disposal: data is wiped, hardware is recycled, and records are archived.

Step 7 – Demonstrating conformance

Before the second release, an independent assessor appointed by Brightway assesses five processes using a process assessment model based on the 12207 process reference model. The profile shows configuration management and verification at capability level 3, project planning and risk management at level 2, and measurement at level 1, because measures are collected but not consistently analysed. Northline adds an improvement action, and the agreement is satisfied. Nobody receives a "12207 certificate"; what Brightway receives is evidence it can trust.

Notice what made this work: a declared set of processes, a recorded tailoring rationale, outcomes as the measure of success, recursion across system levels, and evidence produced as a side effect of everyday tooling rather than as separate paperwork.

Lesson 7 – Relationship to other standards and frameworks

12207 sits at the centre of a large family of standards from ISO/IEC JTC 1/SC 7 and the IEEE Computer Society. Most of them either elaborate one 12207 process in more depth or build on the process model for a specific purpose. Knowing the neighbours helps you pick the right document for each question.

Standard or framework	What it covers	Relationship to 12207
ISO/IEC/IEEE 15288:2023	System life cycle processes	Same 30 processes with the same purposes and outcomes; activities and tasks written for systems engineering. Choose by the system-of-interest: software-intensive or broader system.
ISO/IEC/IEEE 24748-1 and 24748-3	Guidelines for life cycle management and for applying 12207	Explain stages, life cycle models and how to apply 12207 in practice; guidance, not requirements.
ISO/IEC/IEEE 15289	Content of life cycle information items	Defines what plans, specifications and reports should contain; 12207 points to it instead of defining documents.
ISO/IEC 330xx family (33002, 33020, TS 33061)	Process assessment	33002 sets assessment requirements and 33020 the capability levels 0–5; the assessment model TS 33061 builds on the 12207 process reference model.
Process-specific standards (IEEE 730, ISO/IEC/IEEE 29148, 29119, 16085, 15939, IEEE 828, 14764)	Quality assurance, requirements, testing, risk, measurement, configuration, maintenance	Each elaborates one or a few 12207 processes in far more depth.
ISO 9001 with ISO/IEC/IEEE 90003	Quality management system and its application to software	12207 is designed to be compatible with ISO 9001 requirements; ISO 9001 is certifiable, 12207 is not.
ISO 26262-6, IEC 61508-3, IEC 62304, DO-178C	Safety-related software in vehicles, industry, medical devices, airborne systems	Domain standards add safety requirements on top of generic life cycle processes; 12207 provides the common vocabulary and backbone.
CMMI and Automotive SPICE	Process improvement and capability models	Independent models with their own appraisal or assessment schemes; their process areas overlap heavily with 12207 processes.

12207 or 15288?

The choice depends on the system-of-interest. If the system is essentially software (an online service, a mobile app, a software product), 12207 is the natural reference. If it is a broader system in which software is one element among hardware, mechanics and people (a vehicle, a train, a medical device), 15288 frames the whole system and 12207 can be applied to the software elements within it. Because the purposes and outcomes match, organisations can use both without conflict, and many safety-critical projects do exactly that.

Safety-critical and automotive contexts

The course list places 12207 under automotive and safety-critical engineering because it is the generic layer beneath many domain standards. Automotive SPICE grew out of the ISO/IEC 15504 assessment approach, whose software processes were based on 12207. ISO 26262 part 6 describes software development for road vehicles in its own terms, but its expectations for requirements, architecture, unit verification, integration and testing line up with 12207 technical processes, and the supporting processes in ISO 26262 part 8 (such as configuration management, change management, verification and documentation management) line up with 12207 configuration management, information management and verification. The medical software standard IEC 62304 similarly takes the general life cycle idea and adds what regulators need for patient safety. A useful rule: use the domain standard to decide what level of rigour and which specific safety activities are required, and use 12207 to organise how the whole life cycle fits together.

What 12207 is not

It is not a maturity model (it defines processes, not levels; levels come from the 330xx assessment family). It is not a management system standard with certification. It is not a method such as Scrum or SAFe. And it is not a documentation standard. Keeping these distinctions clear prevents a lot of wasted effort.

Common pitfalls and best practices

Pitfalls to avoid:

Treating the technical processes as a waterfall. The list order is not a schedule. Reading it as phases leads to late integration and late validation, exactly what modern practice tries to avoid.
Generating documents instead of outcomes. Producing a template for every information item creates paperwork that nobody reads, while the outcomes the documents were meant to evidence remain unachieved.
Claiming conformance without a declared scope. "We follow 12207" means little unless you name the processes and the form of conformance.
Tailoring silently. Dropping processes without recording the reason turns legitimate tailoring into an unexplained gap that an assessor or acquirer will challenge.
Forgetting the non-technical processes. Teams often cover the technical processes well but have no owner for knowledge management, measurement or disposal.
Selling or buying a "12207 certificate". There is no accredited certification scheme for the standard; such claims mislead customers.

Best practices:

Start from outcomes. For each declared process, ask which outcomes you must be able to show, then design the lightest practice that produces them.
Build a process-to-role matrix early. Make sure every declared process has an owner and that handovers between organisations are explicit in the agreement.
Let tools produce the evidence. Use version control, issue trackers and pipelines so that configuration records, traceability and verification results are created automatically.
Apply processes recursively. Run requirements, architecture and verification at each level of the system structure, with clear interface baselines between levels.
Use the domain standard for rigour and 12207 for structure. In safety-critical work, let the domain standard set integrity requirements and map them onto the 12207 backbone.
Assess for improvement, not for a score. Use capability profiles to choose the next improvement, and repeat assessments to show progress.

Summary and key takeaways

ISO/IEC/IEEE 12207:2026 is the current joint edition; it replaced the 2017 edition and keeps its 30-process architecture.
The processes fall into four groups: agreement (2), organizational project-enabling (6), technical management (8) and technical (14).
Each process is described by purpose, outcomes, activities and tasks; purpose and outcomes form the process reference model used in assessment.
The standard prescribes no life cycle model or method; processes are applied iteratively, recursively and concurrently, so agile and DevOps are fully compatible.
Conformance is claimed for a declared set of processes, as full conformance to outcomes, full conformance to tasks, or tailored conformance with recorded reasons.
There is no certificate for 12207 itself; evidence comes from self-declaration, acquirer evaluation and process assessments under the ISO/IEC 330xx family.
12207 shares its process model with ISO/IEC/IEEE 15288 and provides a generic process backbone that domain standards and models such as ISO 26262, IEC 62304 and Automotive SPICE map onto well.

Reflection questions

Pick a software system you work on. What is the system-of-interest, which enabling systems support it, and which of those enabling systems have their own life cycles you do not control?
Take three of the 30 processes that your team performs informally. What outcomes could you already show evidence for today, and where is the evidence missing?
If you were the acquirer in the worked example, which processes would you insist on full conformance to tasks for, and why would outcome-based conformance be enough for the rest?
How would you explain to a sceptical agile team that 12207 does not require a waterfall life cycle or heavy documentation? Which concrete practices of theirs map to which processes?
In a safety-critical project you know, which requirements come from the domain standard and which belong to the general life cycle framework? Where could the two be confused?