ISO 9001 clause 8.3.6: assess design changes before their effects spread

What clause 8.3.6 requires in practice

Designs rarely stay still. This clause expects the organisation to identify, review and control changes made during design and development, and also those made afterwards, to the extent needed so that conformity to requirements is not adversely affected. The point is not to prevent change but to make sure its consequences are understood before it takes effect.

Evidence must be available for four things: the changes themselves, the results of the reviews carried out, the authorisation given, and the actions taken to prevent adverse effects.

In practice this means a way to recognise a change as a design change, a review that considers what else is touched, a decision by someone with proper authority, and follow-through on any protective actions. Changes made after release, for example to correct a fault or substitute a part, fall within the clause just as much as changes made during development.

Determine the effect, not just the size of the edit

A small-looking change can alter an important characteristic or interface. Conversely, an extensive editorial revision may have little technical effect. Assess the change in relation to requirements, intended use and subsequent provision rather than relying only on the number of pages or lines modified.

Identify connected outputs and processes. A changed design characteristic may affect purchasing, production, test information, installation or support. The review should be sufficient to recognise those consequences and determine the necessary response.

Why controlling design changes matters to the business

Many costly quality failures start with a change that seemed minor. A swapped component, an adjusted setting or a tweaked workflow can disturb something elsewhere that nobody thought to check, and the problem reaches customers before it reaches the design team. Disciplined change control protects products already in the field, avoids confusion between versions, and keeps commercial commitments intact. It also supports regulatory and customer expectations around traceability. Auditors often sample recent changes and ask who reviewed them and on what basis; clear answers show that the design remains under management control long after first release.

How to implement clause 8.3.6

Make it easy to raise a change and hard to slip one through unnoticed. Include changes requested after release, since these are the ones most often handled informally by whoever happens to receive the request. Check regularly that this route is still the one used.

1. Define what counts as a design change, including corrections after release, supplier-driven substitutions and customer-requested modifications.
2. Provide one route for requesting changes, with a clear description of what is changing and why.
3. Review each change for effects on requirements, intended use, interfaces, delivery, purchasing and support, using people who understand those areas.
4. Decide who may authorise changes of different significance, and make sure the decision happens before implementation.
5. Identify what must be done to protect conformity, for instance retesting, updating instructions or informing affected customers, and assign owners.
6. Keep records of the change, the review, the authorisation and the protective actions, and check periodically that the route is being used.

Illustrative manufacturing example: a substituted design element

Illustrative software example: a shared feature change

A hypothetical software supplier modifies a shared feature to meet one customer's new requirement. The same feature is used by other customers with different configurations. A local development team initially evaluates only the requesting customer's case.

The change review identifies the broader dependency and determines appropriate evaluation for affected uses. It updates relevant output information and preserves the review and authorisation evidence. The organisation checks the actions intended to avoid adverse effects before relying on the changed design. A successful result for the requesting customer alone would not establish that every relevant existing use remains suitable.

Use appropriate review and authority

Determine who has the competence and authority needed for the change decision. This may involve more than the person who edits the design. Technical, operational and customer-related input can be relevant depending on the effect. The standard does not impose a universal change-board format.

Consider whether earlier verification or validation needs to be repeated or supplemented. The necessary extent depends on the change and its consequences. Do not assume every change requires all earlier activities to be repeated, but do not assume an earlier approval remains sufficient without examining what changed.

Preserve the required evidence

Connect design changes with other controls

A design change may also alter customer requirements, provider information or production and service arrangements. Apply the relevant provisions together. A completed design approval does not automatically ensure the customer has accepted a changed commitment or that a provider has received revised requirements.

Common failures include unrecorded informal changes, review limited to the originating team and missing authorisation evidence. Another is changing the output without updating related acceptance criteria. Follow one change through its affected interfaces to check whether the organisation controlled the consequence as well as the edit.

Read this within clause 8.3 design and development. Inputs, controls and outputs provide the basis against which the effect of a change can be understood.

Common nonconformities with clause 8.3.6

Findings tend to arise where changes bypass review or leave no trail. Examples seen in practice include the following, each of which weakens confidence that the released design still matches what was approved.

• Design changes after release are made informally by a developer or engineer and no review is recorded.
• Reviews consider only the item changed and ignore connected outputs such as test information, instructions or purchasing details.
• Records show no evidence of who authorised the change, or authorisation occurred after implementation.
• Protective actions identified at review, such as retesting, were never completed or checked.