ISO 9001 clause 8.6: release products and services with evidence

What clause 8.6 requires in practice

Release is the moment output becomes the customer's. Before then, the organisation implements planned arrangements, at suitable stages, to verify that product and service requirements have been met. Release to the customer does not go ahead until those arrangements have been completed satisfactorily, unless a relevant authority, and where applicable the customer, approves otherwise.

Documented information must be available as evidence of release, and it must include two things: evidence that the acceptance criteria were met, and traceability to the person or persons who authorised the release.

The clause does not insist on one gate at the end. Checks can be spread across stages. What it does require is that nobody can ship or hand over by accident, that exceptions are authorised by people with the right standing, and that the record shows who decided.

Plan what makes release acceptable

Acceptance criteria need to be understandable before work reaches the release stage. Draw them from the agreed requirements and relevant operational plans. Decide where verification is useful: some characteristics can be checked during work, while others need a final review. A late check cannot reliably replace an earlier verification when the characteristic is no longer accessible.

Identify the evidence the authoriser needs and how unresolved results will be handled. A pass tick without a clear criterion may conceal a subjective judgement. Conversely, a large bundle of test data is not helpful if nobody can connect it to the delivered output or determine whether the acceptance threshold was met.

Define release authority in a way that fits the process. ISO 9001 does not require a separate quality department to sign every release. It does require traceability to the person or people authorising it. An automated workflow should preserve that accountability and the relevant evidence rather than turn release into an untraceable system event.

Why a controlled release matters to the business

Release is the final defence before a defect becomes a customer problem. When the step is informal, deadlines pressure people into sending work out unchecked, and the organisation discovers later that nobody can say who agreed. A disciplined release reduces returns, claims and reputational damage, and it protects individuals by making accountability clear. It also gives customers confidence that deliveries meet agreed criteria. Auditors usually examine released items or completed jobs and look for acceptance evidence and a named authoriser, so a consistent release record is some of the strongest proof available that planned controls actually operate.

How to implement clause 8.6

Make release a recognisable event with its own checks, authority and record. Allow for urgent situations by defining a documented, authorised exception route, since an unplanned shortcut is far riskier than an approved one. Involve customer-facing teams so that the arrangements reflect real delivery pressure.

1. Decide, for each offering, which verification checks must be complete before output can leave the organisation, and at which stages they occur.
2. State the acceptance criteria clearly so that those checking can say yes or no without guessing.
3. Name who may authorise release, including who may approve a release before all checks are complete and whether the customer must agree.
4. Set up the process, whether a system block, a signed form or a checklist, so that release cannot be skipped by accident.
5. Capture results of the checks and the identity of the authoriser in a single retrievable record for each release.
6. Review early releases and exceptions periodically to see whether pressure is eroding the control.

Evidence an auditor expects for clause 8.6

Auditors usually sample released items or completed engagements and look back at the trail. Sampling releases made under pressure, such as at month end or before a go-live, is a favourite auditor technique.

• Inspection, test or review results showing conformity to the acceptance criteria.
• Records identifying the person or persons who authorised release.
• Evidence of any exception, including who approved it and whether the customer agreed.
• Observation of the point of release to see that checks are completed before output leaves.

Common nonconformities with clause 8.6

Typical findings concern gaps in the release trail. These suggest that release is treated as an administrative step rather than a control that stops unverified output reaching customers. Several of these often appear together.

• Output is delivered before inspection or testing is finished, with no approved exception.
• Records show checks were done but do not identify who authorised release.
• Acceptance criteria are not defined, so the result of a check cannot be judged consistently.
• Urgent shipments or go-live decisions regularly bypass the normal release steps.

Illustrative manufacturing example: a dispatch decision

Illustrative service example: a client reporting pack

A BPO provider produces a monthly reporting pack for a client. The planned acceptance checks include reconciliation to the source period, correct customer allocation and confirmation that sensitive information is not included in another client's output. The service owner reviews the completed checks before permitting the file to be sent.

A reconciliation discrepancy keeps one report from release while the unaffected reports are assessed on their own evidence. After correction and verification, the record links the relevant version, check results and release authoriser. Delivery by email does not make the release decision less significant than a physical shipment; the output can still be wrong or delivered prematurely.

Handle exceptions without obscuring their meaning

The clause allows an approval route when planned arrangements have not been satisfactorily completed. That is a controlled exception, not permission to disregard requirements. Establish what remains unresolved, who has the relevant authority, and whether customer approval applies. Other obligations can restrict what may be accepted or delivered.

Where an output is known to be nonconforming, connect the decision with control of nonconforming outputs, including any concession. Do not relabel a failed characteristic as a passed check simply because an authorised exception has been agreed. The evidence should preserve both the actual result and the decision about it.

Required release information should demonstrate conformity to acceptance criteria and identify the authoriser. Useful supporting details may include the output reference, applicable revision, verification date and links to test or review results. Those fields are implementation choices where helpful; the standard does not prescribe one release certificate format for every industry.

Common failures include shared accounts that obscure who approved release, approvals detached from the tested version, and a status change triggered by schedule completion rather than satisfactory verification. Review whether people can retrieve the decision and understand it after delivery. A record that exists but cannot be tied to the output offers weak assurance.