ISO/IEC/IEEE 90003 and ISO/IEC 12207: The Software-Specific Standards

TheThe previous page ended on a problem: ISO 9001 was written for physical manufacturing, and its vocabulary doesn't map cleanly onto software. The ISO family's own answer to that problem isn't a replacement standard — it's two companion standards that sit alongside ISO 9001, translating and extending it specifically for software. Neither is something an organisation gets "certified in" on its own; both exist to make ISO 9001 actually usable by a software organisation.

ISO/IEC/IEEE 90003: Translating the Vocabulary

ISO/IEC/IEEEISO/IEC/IEEE 90003 (current edition 2018, aligned with ISO 9001:2015) is titled, precisely, "Software engineering — Guidelines for the application of ISO 9001 to computer software"¹. That title says exactly what it does: it does not add new requirements on top of ISO 9001, and it does not change what ISO 9001 demands. It takes ISO 9001's generic, manufacturing-flavoured requirements and restates them in terms that make sense for software — where "product testing" becomes code verification, validation, and regression testing; where "production" becomes the software development lifecycle; where "nonconforming product" becomes a defect or a failed test².

The practical consequence of this design is easy to get backwards: a company doesn't get "ISO 90003 certified." Certification happens against ISO 9001 itself; 90003 is the implementation roadmap an organisation uses to figure out what ISO 9001's clauses actually mean for a software development shop, not a separate certifiable standard sitting next to it. It's guidance for interpreting a requirement, not an additional requirement.

ISO/IEC 12207: The Software Lifecycle Standard

ISO/IECISO/IEC 12207 takes a different, complementary approach: rather than translating ISO 9001's manufacturing vocabulary, it defines, from scratch, a dedicated process architecture for the entire software lifecycle — acquisition, supply, development, operation, and maintenance, plus a set of supporting and organisational processes around them³. Where 90003 answers "what does ISO 9001 mean for software," 12207 answers a more basic question: "what are the actual processes a software lifecycle consists of, named and defined precisely enough that two organisations can agree they're both doing the 'same' process even if their tooling and methodology look completely different." The two standards reference each other directly — the current 90003 explicitly points to 12207 for lifecycle-process detail¹ — because a QMS guideline for software needs some stable definition of what "the software lifecycle" actually consists of, and 12207 is that definition.

This is worth contrasting directly with the delivery methodologies covered elsewhere in this series: 12207 doesn't compete with Waterfall or Scrum as a way of organising work, and it doesn't care which one a team uses. It operates at a different level of abstraction — process categories that any lifecycle model, sequential or iterative, has to address somehow (acquisition, requirements, verification, maintenance), independent of the specific method chosen to move through them.

How the Three Standards Actually Fit Together

Standard	What it is	Certifiable on its own?
ISO 9001	Generic QMS requirements: documented process, PDCA, traceable records, third-party audit.	Yes — this is the standard an organisation is actually certified against.
ISO/IEC/IEEE 90003	Guidelines translating ISO 9001's requirements into software-specific terms.	No — used as an implementation roadmap for ISO 9001 certification.
ISO/IEC 12207	A defined process architecture for the whole software lifecycle.	No — a process-definition standard 90003 and others reference, not itself a certification target.

TheThe overall shape, then: ISO 9001 is the thing an organisation is actually assessed and certified against; 90003 is how a software organisation interprets what that means in practice; 12207 supplies the shared vocabulary of lifecycle processes both of the others rely on. None of the three specify a delivery methodology — see CMMI for the alternative, non-certification approach to the same underlying question of software process quality, built specifically around measuring organisational maturity rather than compliance.

References