ISO 9001 for technology and software: a quality system built into your SDLC

Why technology and software firms are asked for ISO 9001

The request tends to arrive in a bid pack rather than a security review. Government departments, banks, telecoms operators and large manufacturers issue tenders for custom development, implementation or managed IT services, and a current quality certificate is one of the eligibility lines. Prime contractors and global integrators ask the same of the local partners they subcontract build and support work to, because their own customers hold them accountable for the partner's output.

The pressure behind it is delivery risk. Buyers of integrations and bespoke platforms have usually lived through a late go-live or a regression that reached users. ISO 9001 gives that buyer evidence that requirements are agreed before work starts, that changes are controlled, that nothing is released without defined acceptance, and that defects lead to a fix of the cause.

There is guidance written for this sector: ISO/IEC/IEEE 90003 explains how to apply ISO 9001 to software acquisition, supply, development, operation and maintenance. It adds no requirements; it is the interpretation many software auditors carry in their heads.

Scope for a software house, integrator or SaaS provider

A sound scope names what you actually sell: bespoke software development, implementation and integration of third-party platforms, application support, managed services, or the design, development and operation of your own product. It covers the delivery centres where that work is done, including offshore or nearshore teams under your control, and the presales function that agrees requirements.

Outsourced parts stay inside your responsibility. Freelance developers, a partner doing testing, hosting on a hyperscaler and third-party components are external providers you must select and monitor.

Three scope mistakes are common in this sector. Leaving out design and development because "we just follow the client's spec", when your team writes the user stories and the architecture. Certifying only the development team while support and incident handling, where customers feel quality most, sit outside. And writing a scope around one flagship product when tenders are won on project delivery. The general rules are in ISO 9001 scope: how to define it, and the mistakes that cost you.

Where the requirements bite in software delivery

Every clause is explained in the ISO 9001 requirements guide.

ISO 9001, ISO/IEC 27001 and ISO/IEC 20000-1: which does a buyer mean?

Read the tender wording before choosing. A request about delivery quality, project governance or supplier approval points to ISO 9001. Questions about data protection, access control, hosting or penetration testing point to ISO/IEC 27001, and many enterprise buyers ask for both. A managed services, outsourcing or service desk contract that talks about service levels, incidents and availability often names ISO/IEC 20000-1, the service management standard, which itself states that it can be integrated with an ISO 9001 system.

All three share the harmonised structure, so one context analysis, one risk process, one internal audit programme and one management review can serve them. Your ticketing system can hold defects, incidents, problems and security events in one place with different workflows.

What a software engagement looks like

Duration depends on consistency: one engineering process across all projects moves faster than a different practice per team. The engineering or delivery head, a product owner or project manager, QA, support and the commercial owner of contracts must be involved, with a sponsor who protects their time. With Design™, Sterling guides your leads to define the process and own the evidence; with Drive™, Sterling carries more of the documentation, internal audit and readiness work while teams keep delivering sprints.

ISO 9001 for technology and software: questions buyers ask