ISO 9001 clause 8.2.3.1: test requirements and capability before commitment

What clause 8.2.3.1 requires in practice

Clause 8.2.3.1 begins with a plain expectation: the organisation must be sure it can meet the requirements of the products and services it offers. Before committing to supply a customer, it must carry out a review. The review must include the requirements the customer has defined, including those for delivery and for activities after delivery where they apply, and requirements the customer has not stated but which are needed for the known specified or intended use.

It must also include requirements the organisation itself specifies, the statutory and regulatory requirements applicable to the offering, and any contract or order requirements that differ from what was expressed earlier. Those differences must be settled. Where a customer gives no written statement of requirements, the organisation confirms them before acceptance. A note acknowledges that for situations like internet sales a formal review of each order is impractical, so the review may instead cover the product or service information published, for example on a website or in a catalogue. The clause does not name a form, a committee or an approval level. It expects a genuine test of capability, and the way it is run is left to the organisation.

Understand the requirement beyond its headline

Customer-defined requirements can include delivery and post-delivery activities, not only the visible product or immediate service. Consider what the organisation knows about intended use where that reveals necessary requirements the customer has not stated. This does not mean inventing every possible future use; it means using relevant known information responsibly.

The organisation's own requirements and applicable statutory and regulatory requirements also matter. A customer's acceptance of a limited description does not automatically remove those obligations. Obtain appropriate technical or legal input where interpretation exceeds the review team's competence.

Why testing capability before commitment pays

Capability gaps are cheapest to deal with before they become promises. A review that asks whether the right people, equipment, skills, materials and legal permissions will exist when needed lets the business act while options are open. It can ask for time, adjust the scope, propose an alternative or decline. After commitment, the same gap forces rushed substitutions, overtime and compromised results. The review also catches hidden requirements, such as a known application that raises the standard the work must meet. That protects the customer from harm and the business from liability. For auditors, a visible link between a known requirement and the capability check shows that the organisation understands its own limits.

How to implement clause 8.2.3.1

Make the review test something specific, otherwise it turns into a signature. One way Sterling's teams do this is to ask three questions for each order: what exactly was asked, can we do it, and what could we have missed.

1. Read the order or request against the customer's stated needs and write down any point that is unclear or open.
2. Ask what the customer will use the result for, and note any requirement that follows from the known use.
3. Check internal specifications, applicable legal rules and any delivery or post-delivery obligations that apply.
4. Ask delivery owners to confirm availability of people, skills, equipment, materials and time for the committed dates.
5. Compare the order with prior quotations, discussions or messages, and resolve differences before acceptance.
6. Where nothing is in writing, send the customer your understanding for confirmation before work begins.
7. Decide whether to accept, adjust or decline, and tell the customer clearly.

Illustrative manufacturing example: a known application

Illustrative BPO example: an undocumented reporting request

A hypothetical BPO provider discusses a new service by telephone. The customer expects an additional reporting breakdown, but the standard proposal does not include it. The account manager assumes operations can add it later and accepts the work without confirmation.

A stronger review confirms the customer's requirement and examines whether the data and reporting capability exist. Any difference from the proposal is resolved before the commitment. The resulting accepted basis reaches the team responsible for delivery. The example does not require a particular signature format; it requires a clear, reviewed understanding rather than an unsupported verbal promise.

Resolve differences explicitly

Compare the proposed contract or order with what was previously expressed. A changed sequence, additional approval condition or expanded support obligation can matter even when the price remains the same. Determine how discrepancies are identified and who can resolve them.

Resolution should leave a coherent basis for work. Keeping both versions in a folder without clarifying which governs can transfer the problem to delivery staff. Where the organisation cannot meet the proposed condition, communicate and resolve the position rather than hoping it will not become relevant.

Review capability with the people who know the work

Capability may depend on resources, competence, provider arrangements, timing or technical feasibility. The review method should bring relevant knowledge into significant decisions. A simple standard order may need less review effort than a novel service or complex project, but the necessary confidence should still exist.

For internet or other high-volume sales, review of relevant offering information may be suitable where individual formal review is impractical. The process needs a way to recognise significant exceptions. An automated acceptance route should not silently assume that unusual customer conditions fit a standard capability.

Connect the review with evidence and operations

Common nonconformities with clause 8.2.3.1

Review findings generally describe a commitment accepted on an assumption.

• The business cannot show that capability was tested before the order was accepted.
• A known intended use created a requirement that the review did not consider.
• Differences between the order and earlier quotations were left unresolved.
• A verbal request was accepted without the customer confirming the requirements.
• A website or catalogue is relied upon as the review but contains information the business cannot support, such as an outdated product option or an unrealistic service level.