Toughest ISO 9001:2000 Requirements (7.3.1)

Manufacturing companies with design responsibility will likely have an established design and development process. However, clause 7.3 may be a tough new requirement for many service organizations.

The transition document, Guidance on ISO 9001:2001 – Clause 1.2 Application, states “Design and development has traditionally tended to focus on tangible products, but is equally applicable where the product of an organization is a service”.

In addition, ISO 9001:2000 states that “wherever the term “product” occurs, it can also mean service.

Two of the registration scenarios in the guidance document were for service companies, and in both cases, they were viewed as design responsible and unable to exclude clause 7.3. Since service organizations decide on the new services to be offered, and then define the characteristics of those services, they are carrying out design and development. Unfortunately, many service firms were allowed to exclude design and be assessed against ISO 9002:1994 (instead of ISO 9001:1994).

It is important for organizations to determine (with their registrar) if they carry out design and development activities and, therefore, must apply clause 7.3. If the answer is yes, the first step is to plan the design and development process and identify the necessary controls.

Clause 7.3.1, Design and Development Planning, states:


The organization shall plan and control the design and development of product.


To understand this requirement, lets begin with an ISO 9000:2000 definition. Design and development is the set of processes that transforms requirements into specified characteristics or into the specification of a product, process, or system.

But is there a difference between “design” and “development”? ISO 9000:2000, Note 1, states the terms are sometimes used synonymously and sometimes used to define different stages of the overall design process.

In some organizations, “design” and “development”, refer to the same activities. If that is the case, these groups typically use one term or the other, but not both terms together. In other words, they call it design or they call it development.

However, in other situations, design and development may relate to different stages in the process. First, “design” activities may creatively define the characteristics of a product or service to meet customer requirements. Then, “development” activities would determine the best techniques for applying the design to produce the product or deliver the service. Use of “design and development” would be appropriate to address the combined activities.

Your organization must establish a disciplined approach for the design and development process. The “plan” in 7.3 refers to defining the design and development process, as well as, the sequence and interaction of its activities. The “controls” are generally addressed by the requirements expressed in clauses 7.3.2 to 7.3.7.


During the design and development planning, the organization shall determine

a) the design and development stages
b) the review, verification, and validation that are appropriate to each design and development stage, and
c) the responsibilities and authorities for design and development  


Design and development processes can be grouped into stages, e.g., a preliminary (high-level) design stage and then a detailed (low-level) design stage. Typically, stages have “entry” criteria that must be satisfied to initiate the activities and “exit” criteria to be met before moving to the next stage. Reviews are often held at the end of a stage to see if the exit criteria has been met and to decide whether to proceed to the next stage or to repeat some activities of the current stage.

An organization may decide on a multi-stage process for high-risk designs and abbreviated versions for lower-risk designs. Since it is a design process “plan”, it can be revised using interim results to add or repeat a stage, to drop an unnecessary stage, or to change the activities within the stages.

Design and development planning determines the appropriate review (7.5.4), verification (7.5.5), and validation (7.5.6) for each stage.

review formally checks the output of a stage to confirm it will meet the input requirements. The review also identifies any problems and develops solutions. For a simple design, one review may be sufficient. For a complex design, frequent reviews may be necessary to evaluate progress and manage the risk. ISO 9000:2000 defines “review” as the activity undertaken to determine the suitability, adequacy, and effectiveness of the subject matter to achieve established objectives.

Verification ensures the results of the process (7.3 – Output) meet the requirements identified at the beginning of the process (7.3.2 – Input). For multi-stage projects, verification may be performed on a stage-by-stage basis. ISO 9000:2000 defines verification as the confirmation, through the provision of objective evidence, that specified requirements have been fulfilled.

Validation checks that the final product or service meets, or is capable of meeting, the customer requirements when used in the intended environment. In some cases, this may be done at final test, or the customer may carry out the validation as an acceptance test. Validation occurs in the final design and development stage and relies upon prior successful verification. ISO 9001:2000 defines validation as the confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled.

For both verification and validation, the plan should identify who carries out the activities, the methods to be used, how they will be performed, and what records are to be kept. In some industries, the planning for design and development is part of the overall project plan.

When assigning responsibilities, the first assignment should be to name a process owner for the overall design and development process. That person can use the design and development plan to identify the different activities and decide on the remaining assignments. If the plan doesn’t exist, their first task will be to help create it.


The organization shall manage the interfaces between different groups involved in design and development to ensure effective communication and clear assignment of responsibilities.


The larger the company, the more departments and people involved in the design and development process. Even in a small company with one designer, there will be other parties to consider, such as, customers, suppliers, and regulatory bodies. All these groups must be identified and their interfaces managed to ensure they are talking about the right subjects and sharing the appropriate information. The groups must clearly understand their responsibilities to avoid any overlapping or overlooked assignments. Managing the interfaces includes using the appropriate communication methods to keep them informed and to make timely decisions
Remember that clause 7.3.3 requires the design and development output to include information for the purchasing, production, and service areas. These groups should be included in the interfaces and relationships to be defined and managed.


Planning output shall be updated, as appropriate, as the design and development progresses.


An active design and development “plan” is a document with a revision status, not a record with a retention period. Plans are just that, plans. You should expect that as stages complete, the results may require the plan to be revised. If the design and development process is well defined and managed, the organization is more likely to meet requirements on time and within budget.

Before leaving this discussion, I should point out that the note in 7.1 says that 7.3 could be applied to the design and development of processes, not just products.