ISO 9001 clause 8.3.1: establish a design process suited to the offering
ISO 9001:2026 clause 8.3.1 requires the organisation to establish, implement and maintain an appropriate design and development process to support subsequent provision of products and services. The process should help turn requirements into an offering that can be delivered successfully. It must fit the nature of the organisation's design work.
What clause 8.3.1 requires in practice
Clause 8.3.1 sets the general expectation for design and development. The organisation must set up, run and keep up a design and development process that is suited to making sure products and services can be provided afterwards. Each of the three verbs matters. Establish means the process is defined, implement means it is actually used, and maintain means it is kept suitable as the work and organisation change.
A note recognises that review, verification, validation and feedback may run in repeated cycles, so an iterative approach is acceptable throughout design and development. That removes any suggestion that the standard favours a rigid sequence. The test is appropriateness: a process for a small software feature will look different from one for a regulated physical product. The clause is also the gateway to the more detailed provisions that follow, covering planning, inputs, controls, outputs and changes, so it should be read as setting the frame for them. It does not name a method, a toolset or a document, and it does not require an organisation without design responsibility to invent one. Applicability follows the scope of the system.
Recognise where design decisions occur
Design is not limited to a department with that title. A service business may decide the structure, rules and interfaces of a new offering. A manufacturer may determine product characteristics, while a software team develops behaviour to meet customer needs. Examine actual responsibilities rather than relying on the organisation's preferred label.
Applicability belongs within the QMS scope decision. A business delivering strictly to an authorised customer design may have a different responsibility from one specifying or adapting the design itself. Outsourcing some design work does not automatically remove the organisation's retained obligations.
Why a suitable design process matters
Without an agreed process, design depends on individual habits. Some projects are reviewed carefully while others reach customers with untested assumptions, and the business cannot predict which will happen. A process that fits the work gives consistent expectations about who decides what, when checks happen and how feedback is used. That raises the chance that new offerings work for customers at the first attempt and reduces expensive correction after the service goes live. It also allows the business to work in a flexible, iterative way without losing control. For auditors, the existence of a working process is the starting evidence that design is managed and not accidental, and it sets the basis for examining specific projects.
How to implement clause 8.3.1
Fit the process to how your teams really develop things, and confirm that it is used. One way Sterling's teams approach it is to describe the actual path of a recent development before drafting anything new.
- Identify who makes design decisions in the business, including teams that do not carry a design title.
- Describe the path from customer or market need to a deliverable offering as it really happens today.
- Decide the main stages or cycles, and where review, verification, validation and feedback fit.
- Define who has authority at each stage and how work passes between teams.
- Check that the process supports later delivery, so operations are involved before the design is final.
- Run one live project through the process, collect lessons and adjust the process where it was awkward or ignored.
- Review the process periodically, so it keeps pace with new technologies, customer expectations and changes in team structure.
Illustrative BPO example: designing an exception service
A hypothetical BPO provider develops a new service for handling customer exceptions. It determines how cases will be classified, what information agents need, when specialist review occurs and what output the customer receives. Those decisions shape the service rather than merely schedule existing work.
The organisation establishes a design process that gathers requirements, tests the proposed workflow and reviews whether it can support the intended use. It connects the design with competence, instructions and operational acceptance. The example demonstrates service design; it does not prescribe a particular BPO workflow or assume that one pilot proves suitability for every customer.
Illustrative manufacturing example: adapting a product family
A hypothetical manufacturer modifies an existing product family for a new customer application. Staff initially treat the work as an ordinary production change because much of the product remains familiar. Review shows that the change affects characteristics important to intended use.
The organisation applies an appropriate design process to the changed requirements, controls and resulting outputs. It considers what can reasonably be reused from earlier work and what needs new evidence. Familiarity can reduce unnecessary repetition, but it does not justify ignoring the effect of a meaningful design change.
Connect the process with delivery
An appropriate design process considers how the resulting product or service will be provided. Outputs need to reach the people who purchase, produce, deliver, support or verify the offering. A design that appears complete within the development team may remain unusable if those interfaces are not addressed.
The following subclauses provide the detailed controls for planning, inputs, reviews and other controls, outputs and changes. Use them together. Clause 8.3.1 establishes the process requirement; it is not a substitute for the more specific provisions that explain how the process is controlled.
Allow iteration without losing the decision basis
Requirements and design understanding may evolve. Iteration can be appropriate when reviews and feedback lead to a better result, provided the organisation manages the evolving basis and the relevant controls. A method described as agile or experimental does not remove the need to know what was evaluated and what was accepted.
Equally, do not add ceremonial approval stages that provide no useful control simply to make the process look formal. Determine the activities needed for the offering's complexity, consequences and relevant requirements. A simple design change and a novel service may justify different arrangements.
Evidence and common failures
Evidence of implementation may include actual design work and the documented information required by the detailed 8.3 subclauses. This general provision does not prescribe one process-diagram format. The organisation should be able to explain how its design approach supports subsequent delivery.
Common weaknesses include denying that service design exists, assuming outsourced design is outside the QMS and relying on a finished output without a clear development basis. Another is maintaining a design procedure that bears little resemblance to actual iterative work. Review a recent design from initial need to operational use and examine the real decisions.
Frequently asked questions
Can agile development meet ISO 9001 design requirements?
Yes, when the process provides the relevant controls and evidence. Iteration does not remove the need to manage requirements, evaluate outputs and address changes appropriately.
Does every service business perform design?
Not necessarily. Examine the actual responsibilities and offering. Do not decide applicability solely from the word “service” or the absence of a design department.
Can an external designer be used?
Yes. Determine retained responsibilities and apply appropriate design and provider controls. Outsourcing alone does not establish non-applicability.
Make the design process reflect actual development work
Sterling can review your design and development approach, connecting implementation, employee learning and scoped Effivity ISO & GRC automation software with delivery interfaces. Independent bodies decide certification.
Enquire about forthcoming ISO 9001 implementation learning. Return to clause 8.3 or continue to design planning.