ISO and software development: what a standard really certifies – and what it does not

“We deliver ISO-certified software.” The sentence appears regularly in tenders and on vendor pages – and is imprecise in almost every case. Understanding what the relevant standards actually refer to leads to wording that is not only more correct but more convincing.

1. The misconception

“ISO” is not a single standard but a standards body with thousands of them. Those relevant in a software context fall into two groups with very different meaning: management system standards, against which organisations can be certified, and technical standards that describe terms, models or processes without there being any product certification for them.

Conflating the two produces the common false conclusion: because a firm is certified to ISO 9001, the software produced there counts as “certified”. In fact the management system is certified – not the product.

2. What ISO is and what gets certified

Certification is issued by accredited certification bodies, not by ISO itself. The subject is a system with a defined scope – for example “development and operation of custom software at site X”. A certificate therefore says: this organisation has, for that area, a management system that meets the standard's requirements and is audited regularly.

What it does not say: that a particular product is defect-free, secure or fit for a particular purpose.

3. The relevant standards at a glance

4. ISO 9001 and the development process

ISO 9001 requires no particular development methodology. It requires that processes are defined, steered, monitored and improved – and that their effectiveness is evidenced. For software development that means in practice: defined flows for requirements, development, testing and release, documented responsibilities and retained records.

Notably, that overlaps almost entirely with what a team needs anyway to keep AI-assisted development manageable. Anyone who has set up quality gates and traceability properly meets a substantial part of these requirements without extra work.

5. ISO/IEC 27001 and information security

Often the more relevant standard for software companies, because tenders ask for it more frequently. It concerns handling information – including client code, credentials and development environments. That is exactly where it touches AI use directly: which content leaves the company, to which provider, on what contractual basis?

A data classification as described in the deep dive AI coding governance is therefore not an additional task but a building block that counts in both contexts.

6. ISO/IEC 42001 and AI

ISO/IEC 42001 describes a management system for the responsible use of AI in an organisation: roles, risk consideration, life cycle, monitoring. The basic rule applies here too: the organisation is certified, not an AI product and not the software built with AI.

For most software companies the standard is currently less a certification target than a usable outline: it shows which questions an AI policy should answer. Certification pays off mainly when clients ask for it.

7. Product-related standards

Product-level requirements in software usually come not from the ISO 9001 family but from sector-specific regulations: IEC 62304 for medical device software, ISO 26262 for road vehicles, EN 50128 for railway applications. There, product-related evidence obligations really do exist – but even there the system in its operating context is assessed, not a framework or a platform “as such”.

8. Wording in proposals

The practical advantage of the right-hand column: it is verifiable and holds up to any follow-up question. The left-hand column falls apart at the latest in the technical conversation.

Checklist: referencing ISO correctly

Conclusion

Standards are not a marketing instrument but a tool for structuring work. Referencing them precisely wins twice: the statement survives scrutiny, and the other side sees that you know the difference between management system, process and product.

The same rule applies to CodamAI as to any vendor: a platform can support ISO-oriented quality processes. That does not make it certified – nor the software built with it.