Review of the requirements for products and services

“Review of the requirements for products and services” is one of the fastest ways to prevent quality failures that start upstream: unclear requirements, informal promises, and unmanaged changes. Clause 8.2.3 pushes you to prove a simple thing: you don’t accept work you cannot deliver as specified. The standard does not prescribe a specific form or tool, but auditors will expect a consistent method that is used for every relevant commitment and scales with risk. ¹

For a Compliance Officer, CCO, or GRC lead supporting a quality management system, this requirement is less about paperwork and more about operational control. You need defined checkpoints, clear accountability, and evidence that requirements were understood and agreed. You also need a change discipline, because many delivery failures happen after the contract is signed, when requirements drift and nobody re-checks capacity or compliance impact. ¹

This page gives you requirement-level implementation guidance you can put in place quickly: who owns what, what “ability to meet requirements” means in practice, what artifacts to retain, what auditors ask, and the execution plan to roll it out without turning Sales and Operations into enemies.

Regulatory text

ISO 9001:2015 Clause 8.2.3: “The organization shall ensure it has the ability to meet the requirements for products and services to be offered to customers.” ¹

Operator interpretation (what you must do):

• Before accepting a customer commitment (quote, contract, statement of work, purchase order, subscription, change order), you must review the requirements and confirm you can meet them with your current capabilities or with planned actions you control.
• “Requirements” includes customer-stated needs, unstated but necessary requirements (for fit-for-purpose delivery), and applicable statutory/regulatory obligations where relevant to your product or service. The review must also cover your own organizational requirements (quality standards, design rules, security obligations you contractually promise, delivery constraints). ¹

Plain-English interpretation

You need a formal “pause point” where someone competent verifies: (1) what the customer is asking for, (2) what you are promising, and (3) whether operations can actually deliver within the specified constraints. If anything is unclear, you clarify it before you commit. If something changes, you re-review and re-approve before you proceed. ¹

A practical way to think about it: your organization should never discover a requirement for the first time during delivery.

Who it applies to (entity and operational context)

This applies to any organization operating an ISO 9001 quality management system that offers products or services to customers. ¹

In practice, it touches these operational moments:

• Sales and pre-sales: quoting, proposals, demos that include commitments, tender responses.
• Contracting: MSA/SOW review, purchase order acceptance, subscription terms.
• Order entry / project kickoff: confirming delivery scope, acceptance criteria, and constraints.
• Change management: scope changes, design changes, delivery date changes, substitutions, and “small” deviations.
• Third parties in the delivery chain: contract manufacturers, logistics providers, software providers, labs, installers; their capabilities can limit your ability to meet requirements.

What you actually need to do (step-by-step)

1) Define what triggers a requirements review (your “acceptance gate”)

Create a short rule set that tells the business when review is mandatory. Common triggers:

• New customer or new product/service line
• Any contract/SOW/PO with bespoke requirements
• Regulated or safety-critical use cases
• New delivery location, environment, or integration
• Any deviation from standard specs or standard terms

Control objective: no commitment leaves Sales/Contracts without the required review and approval for that trigger level. ¹

2) Standardize the inputs you review

Build a minimum “requirements packet” that the reviewer must have. Examples:

• Customer requirements: specs, scope statement, drawings, user stories, acceptance criteria
• Contractual requirements: SOW, SLAs, service credits, warranties, liability caps tied to performance, delivery/incoterms, data handling clauses if applicable
• Internal requirements: QMS procedures, design standards, validation requirements, inspection/test requirements
• External obligations: statutory/regulatory requirements that apply to the product/service offered (where relevant)

Tip: If the packet is incomplete, the review should stop and request clarification. That “stop” is part of the control. ¹

3) Perform the review against a consistent checklist

Your checklist should force explicit confirmation of capability. Include:

• Scope clarity: deliverables and exclusions are explicit; acceptance criteria defined.
• Feasibility: design/technical feasibility; required methods are available.
• Capacity and scheduling: production slots, engineering bandwidth, support coverage, lead times.
• Competence: trained staff available; special qualifications identified.
• Supply chain: required third parties approved/available; long-lead components identified.
• Quality controls: inspection/test/validation steps identified; measurement capability exists.
• Delivery constraints: packaging, labeling, storage, environmental limits, installation constraints.
• Customer communication: escalation paths, change process, and responsibilities defined.

Document outcomes as: approve, approve-with-actions, or reject/renegotiate. “Approve-with-actions” must list owners and due points (for example: qualify a supplier, run a pilot, update work instructions) and must be tracked to closure. ¹

4) Assign decision rights and segregation of duties

Auditors will look for accountable roles:

• Commercial owner (Sales/Account): submits requirements packet; ensures customer clarifications happen.
• Operational owner (Ops/Delivery/Manufacturing): confirms capacity, method, and controls.
• Quality (QA/QMS): ensures review happened, checklist completeness, and that deviations are controlled.
• Legal/Compliance (as needed): reviews contractual/regulatory commitments that affect deliverability.

Avoid a process where Sales “self-approves” deliverability. You can allow fast-track approvals for standard offerings, but define what “standard” means and what evidence proves it. ¹

5) Control changes after acceptance

A strong 8.2.3 program lives or dies on change control. Define:

• What constitutes a change (requirements, design, materials, delivery dates, acceptance criteria, environment)
• How changes are logged (change request)
• Who re-approves (same decision rights as initial review)
• How you communicate changes to affected teams and third parties
• How you prevent “side agreements” (email promises) from bypassing review

If you use a ticketing system, CRM, or contract lifecycle tool, integrate a “requirements review” status and require approval before moving to “won/accepted” or “release to delivery.” Tools like Daydream can help centralize third-party and contractual obligation tracking so the review can quickly confirm supplier capability and dependency risks without chasing emails across teams.

6) Make it auditable: define required records and retention

ISO 9001 expects objective evidence that the organization ensured ability to meet requirements. Your goal is to show the trail from requirement → review → decision → actions → change approvals. ¹

Required evidence and artifacts to retain

Keep artifacts lightweight but consistent. Common, defensible evidence includes:

• Requirements review checklist (completed) tied to the quote/contract/order ID
• The requirements packet reviewed (versioned where possible)
• Approval record (names/roles, date/time, decision, conditions)
• Open actions list for “approve-with-actions,” with closure evidence
• Change requests and re-approvals (including customer approvals where relevant)
• Communication record for clarifications (email thread, meeting minutes, RFI log)
• For third-party dependencies: supplier confirmation, capability assessment notes, or purchase commitment that supports feasibility

Retention should align with your QMS record control approach; be consistent across business lines. ¹

Common exam/audit questions and hangups

Auditors tend to probe “show me” evidence. Expect:

• “Show three recent orders and the requirement review performed before acceptance.”
• “How do you ensure statutory/regulatory requirements are identified for this product/service?”
• “How do you handle changes to customer requirements after order acceptance?”
• “Who can approve deviations from standard specs or standard terms?”
• “How do you ensure a third party in your supply chain can meet the customer’s requirements?”

Common hangups:

• Reviews exist for big deals but not for “routine” orders.
• Checklists are completed after delivery begins (backdating risk).
• Change approvals are informal and not captured as records.

Frequent implementation mistakes (and how to avoid them)

1. Treating the review as a sales formality.
   Fix: require an operations sign-off for any non-standard requirement; embed feasibility checks.

2. No clear definition of “requirements.”
   Fix: define required inputs and minimum acceptance criteria; include acceptance tests and service levels where relevant.

3. Skipping change re-review.
   Fix: create a simple change workflow that triggers re-approval and updates downstream plans.

4. Assuming third-party capability without evidence.
   Fix: require documented confirmation for critical dependencies, especially long lead time items or specialized services.

5. Inconsistent application across teams or sites.
   Fix: standardize the checklist, define triggers, and audit internal compliance with sampling.

Risk implications (why this matters operationally)

If you accept requirements you cannot meet, you create predictable failure modes: rework, missed delivery dates, nonconforming outputs, warranty claims, customer dissatisfaction, and disputes about “what was agreed.” Clause 8.2.3 is a front-end control that reduces downstream corrective action workload because the work enters delivery in a controlled, understood state. ¹

A practical 30/60/90-day execution plan

First 30 days (Immediate)

• Map where commitments happen (quote, contract, PO, change order) and pick the gating point.
• Draft a one-page procedure: triggers, roles, approval rules, required records.
• Build a minimum viable checklist and requirements packet template.
• Pilot on a small set of deals/orders and capture gaps.

Next 60 days (Near-term)

• Expand to all applicable offerings; train Sales, Ops, and QA on how to run the review.
• Add change control rules and a simple change request template.
• Set up a central repository (QMS system, shared drive with controls, or integrated tooling) with versioning and access control.
• Start internal sampling: pick recent commitments and verify the review happened before acceptance.

By 90 days (Operationalized)

• Tune triggers based on pilot results (reduce friction for truly standard orders; increase rigor for bespoke work).
• Add supplier/third-party dependency checks for critical deliveries.
• Establish metrics that don’t rely on invented statistics: review completion rate, late re-approvals found in sampling, volume of “approve-with-actions” and closure timeliness.
• Prepare an audit pack: procedure, checklist, sample records, and evidence of change control.

Frequently Asked Questions

Does ISO 9001 require a written contract review procedure for 8.2.3?

The clause requires you to ensure you can meet requirements before offering/committing, and auditors expect a defined, repeatable process with records. A short documented procedure plus consistent records is the safest way to show conformity. ¹

What counts as “ability to meet requirements”?

It means you have (or will have through controlled actions) the capacity, competence, methods, tools, and supply chain needed to meet the stated and applicable requirements. Your review should confirm feasibility and identify conditions or actions required before acceptance. ¹

We sell standard products. Do we need to review every order?

You still need a mechanism that ensures ability to meet requirements, but you can streamline routine orders by defining what “standard” means and what triggers an exception review. Keep evidence that the order matched standard specs and terms. ¹

How should we handle changes after the customer signs?

Treat changes as new requirements. Log the change, reassess feasibility and impacts, and obtain re-approval before implementing the change in production or service delivery. Keep the change record tied to the original commitment. ¹

What’s the minimum evidence an auditor will accept?

A completed review record tied to a specific quote/contract/order, showing what was reviewed, who approved, and the outcome. If there were conditions or follow-up actions, you need evidence they were tracked and closed. ¹

Where do third parties fit into this review?

If a third party is necessary to meet customer requirements, your ability to meet requirements depends on theirs. Your review should confirm the third party can meet relevant specs, lead times, and quality controls, and that you have a plan if they cannot. ¹

Footnotes

1. ISO 9001:2015 Quality management systems — Requirements