Requirements for products and services

ISO 9001:2015 Clause 8.2 requires you to define customer, statutory/regulatory, and internal requirements for every product or service before you commit to deliver it, and to confirm you can meet those requirements. Operationalize it by standardizing intake, requirement capture, contract/order review, and controlled handoff to delivery with retained evidence. ¹

Key takeaways:

• You need a repeatable method to capture, clarify, and approve product/service requirements before acceptance. ¹
• “Defined requirements” must be traceable into delivery (scope, acceptance criteria, changes, and customer communications). ¹
• Auditors look for consistent contract/order review evidence, not good intentions or tribal knowledge. ¹

Clause 8.2 (“Requirements for products and services”) is where many quality systems either become operational or stay theoretical. It forces a discipline: before you quote, accept an order, sign a statement of work, or start delivery, you must know what the customer wants, what rules apply, what you promised, and whether you can actually deliver it. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest route is to treat this as a controlled “front door” into operations: a single intake and review workflow that captures requirements, resolves ambiguities, confirms capability, and creates an auditable record. If you do this well, downstream controls get easier: design inputs are cleaner, production/service delivery is less chaotic, and customer disputes become easier to close because acceptance criteria and changes were documented.

This page gives requirement-level implementation guidance you can put into practice quickly: who owns what, what artifacts you must retain, what auditors typically probe, and how to avoid common failure patterns (especially “we discussed it on a call” delivery commitments). ¹

Regulatory text

Regulatory excerpt: “The organization shall ensure that the requirements for products and services to be offered to customers are defined.” ¹

Operator interpretation (what you must do):

• You must have a process that results in defined requirements before you accept work. “Defined” means documented in a controlled place, understandable by delivery teams, and specific enough to verify fulfillment (for example: scope, performance needs, delivery method, and acceptance criteria). ¹
• Requirements definition is not limited to the customer’s explicit request. You also need to identify other applicable requirements (for example: regulatory obligations and internal quality commitments) and ensure alignment before committing. ¹
• You must review your ability to meet those requirements before you commit to deliver. If you cannot meet them, you either negotiate changes or decline. ¹

Plain-English interpretation of the requirement

Clause 8.2 expects your organization to avoid “promise now, figure it out later.” Every product or service offer should be backed by a clear, reviewed set of requirements that delivery can follow and quality can verify. ¹

In practice, this becomes a contract/order/SOW review control with three outputs:

1. A requirements record (what the customer and other obligations require).
2. An acceptance decision (we can meet it, or we negotiated changes).
3. A handoff package to delivery (so implementation matches what was agreed). ¹

Who it applies to (entity and operational context)

Entity scope: Any organization operating a QMS under ISO 9001:2015. ¹

Operational contexts where Clause 8.2 shows up:

• B2B services: managed services, consulting, implementation projects, customer support with SLAs.
• Manufacturing and distribution: configured products, build-to-order, labeling/packaging requirements.
• Software/SaaS: subscriptions with uptime/support commitments, security requirements, data processing terms.
• Public sector or regulated customers: higher volume of mandated requirements and required communications.

Functions involved (typical RACI):

• Sales / Customer success: capture stated needs and customer commitments.
• Legal / Compliance: identify statutory/regulatory and contractual obligations; approve risk positions.
• Operations / Delivery: confirm feasibility, capacity, and delivery approach.
• Quality: enforce the workflow, sampling, evidence integrity, and change control. ¹

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

Use this as a practical implementation sequence. Treat each step as a required gate before acceptance.

1) Define the “requirements container”

Pick one controlled system of record per engagement type (quote, order, SOW, contract, ticket). The key is consistency and auditability.

• Minimum fields: customer, offering, scope, assumptions, constraints, acceptance criteria, delivery dates/milestones, SLAs (if any), support model, data/security requirements (if applicable), and applicable regulatory/customer standards. ¹

Practical note: If requirements live across email, CRM notes, and slide decks, you will fail the “defined” test during audit because delivery cannot reliably know what governs. ¹

2) Standardize customer communication and intake

Create a structured intake that prompts the customer-facing team to capture:

• Explicit customer requirements (features, quantities, performance).
• “Known unknowns” that require clarification (dependencies, interfaces, data inputs).
• Delivery constraints (access windows, environment, customer responsibilities). ¹

A simple tactic: a requirements checklist aligned to your offering catalog. Avoid open-ended narratives as the primary record.

3) Identify “other applicable requirements”

Build a short decision tree for non-customer requirements. Examples:

• Is the customer in a regulated industry with mandated controls in contracts?
• Are there export, labeling, safety, privacy, or recordkeeping obligations embedded in the deal documents?
• Do internal quality standards apply (calibration requirements, test evidence expectations, code review standards, etc.)? ¹

Compliance can operationalize this by maintaining a clause library and a review playbook that maps common customer requirements to internal controls and owners.

4) Perform contract/order review before acceptance

Implement a required review gate that answers, in writing:

• Are requirements complete and unambiguous?
• Do we have capability, capacity, competent resources, and suppliers/third parties to meet them?
• Are deviations from standard offering approved (commercial, legal, quality)?
• Are acceptance criteria testable and agreed? ¹

Keep the decision explicit: Accept / Accept with changes / Reject / Escalate.

5) Create a controlled handoff to delivery

Once accepted, requirements must be handed off in a form delivery uses day-to-day.

• Link requirements to delivery artifacts: project plan, work instructions, BOM/configuration, runbooks, test plan, inspection checklist, service ticket templates. ¹

A fast audit check: pick a delivered order and trace backward to the requirements record. If that trail breaks, you have a Clause 8.2 exposure. ¹

6) Control changes to requirements

Even though Clause 8.2 is the focus, auditors will test whether requirement changes remain “defined” after amendments.

• Require change documentation (who requested, what changed, impact, approvals).
• Ensure delivery is working to the latest approved version.
• Preserve history for dispute resolution. ¹

7) Monitor performance signals that indicate requirements quality

Add a feedback loop so the process improves:

• Root causes: rework from unclear requirements, customer disputes, missed SLAs, repeated clarifications after kickoff.
• Preventive controls: stronger checklists, clearer acceptance criteria, better escalation rules. ¹

Required evidence and artifacts to retain

Auditors need proof that your process runs and that it produces defined requirements.

Retain, at minimum:

• Requirements record for each accepted order/SOW/contract (with acceptance criteria and constraints). ¹
• Contract/order review evidence: approvals, sign-offs, capability confirmation, exceptions and escalations. ¹
• Customer communications that clarify requirements (meeting notes, emails) when they materially change scope or acceptance criteria, linked to the requirements record. ¹
• Change records for amendments and scope changes with approvals and version history. ¹
• Delivery traceability artifacts: handoff checklist, delivery plan/runbook, test/inspection results mapped to acceptance criteria. ¹

Tooling note: If you are stitching evidence together manually, a system like Daydream can help centralize request intake, approvals, and evidence collection so each customer commitment has an auditable thread from requirement to delivery.

Common exam/audit questions and hangups

Expect auditors to probe these areas:

• “Show me how you ensure product/service requirements are defined before acceptance.” ¹
• “Pick a recent order. Where are the requirements documented, and who approved acceptance?” ¹
• “How do you handle unclear requirements?” Look for documented clarification and updated requirements. ¹
• “How do you confirm you can meet requirements?” Auditors will expect evidence of feasibility/capability review, not informal confidence. ¹
• “What happens when requirements change midstream?” They will look for change control and communication to delivery. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails Clause 8.2	How to fix it
Requirements are buried in emails or calls	Not reliably “defined” or repeatable	Require a single requirements record and link supporting comms to it. 1
Acceptance criteria are missing	You can’t prove you met requirements	Add explicit acceptance fields (test method, sign-off owner). 1
Sales commits to nonstandard terms without review	Organization may accept work it can’t meet	Enforce a pre-acceptance review gate for deviations. 1
Changes happen but the “source of truth” is not updated	Delivery works to outdated requirements	Formalize change control and versioning for requirements. 1
No evidence of feasibility/capacity check	You can’t show you reviewed ability to meet requirements	Add a capability checklist and required approval from delivery/ops. 1

Enforcement context and risk implications

ISO 9001 is a certifiable standard, not a regulator. The “enforcement” you face is typically customer audits, certification audit nonconformities, and commercial fallout from disputed scope and failed acceptance. Clause 8.2 weaknesses create predictable risks:

• Contract disputes due to unclear scope and acceptance criteria.
• Rework and missed deadlines caused by incomplete requirements.
• Quality escapes because delivery built the wrong thing or delivered against outdated requirements. ¹

A practical 30/60/90-day execution plan

You asked for speed. This plan prioritizes minimum viable control first, then maturity.

First 30 days (stabilize the front door)

• Inventory where requirements currently live (CRM, email, contracts, tickets) and pick a single system of record per work type. ¹
• Publish a one-page “requirements must be defined before acceptance” procedure and a requirements template. ¹
• Implement a mandatory acceptance gate for new work: sales cannot mark “closed won” or operations cannot start without a completed requirements record and review sign-off. ¹

Days 31–60 (make it auditable)

• Add a contract/order review checklist with explicit capability checks and escalation paths. ¹
• Train sales, customer success, and delivery leads on what “defined requirements” means and what evidence must exist in the record. ¹
• Pilot traceability: sample recent engagements and verify you can trace requirement → acceptance decision → delivery artifact. Fix gaps immediately. ¹

Days 61–90 (reduce rework and disputes)

• Formalize change control for requirements amendments (versioning, approvals, customer confirmation where needed). ¹
• Build a clause library for common customer/regulated requirements and map ownership (legal, compliance, ops). ¹
• Automate evidence capture where possible (workflow tools; Daydream can help create consistent intake, approvals, and evidence packaging for audits).

Frequently Asked Questions

What counts as “defined requirements” under ISO 9001 Clause 8.2?

Requirements are “defined” when they are documented in a controlled place, complete enough for delivery to execute, and specific enough to verify acceptance. If delivery still needs major clarification after kickoff, your definition step is probably failing. ¹

Do we need a contract review for every small order or ticket?

The standard requires you to ensure requirements are defined before offering and accepting work, but you can scale the rigor. Use a lightweight checklist for low-risk, standard work and a deeper review for nonstandard commitments. ¹

How do we handle ambiguous customer requirements without slowing sales cycles?

Put ambiguity into a required clarification step with a short list of questions and a documented customer response. If the customer cannot clarify, treat the work as “accept with changes” by narrowing scope and defining assumptions. ¹

Are statutory and regulatory requirements part of Clause 8.2 even if the customer doesn’t mention them?

Yes. Your requirement definition must include applicable obligations beyond the customer’s stated wants, and you must confirm you can meet them before acceptance. Keep the mapping in your requirements record or review checklist. ¹

What evidence will an auditor ask for first?

Usually a sample order/SOW and proof of the review and acceptance decision, plus the documented requirements and any changes. They will then test traceability into delivery artifacts and acceptance results. ¹

We’re SaaS. Do “product requirements” include SLAs and support terms?

Yes if you offer them as part of what the customer buys. Capture them as requirements with measurable terms and make sure operations/support can meet them before you commit. ¹

Footnotes

1. ISO 9001:2015 Quality management systems — Requirements