Determining the requirements for products and services

ISO 9001:2015 Clause 8.2.2 requires you to define product and service requirements before you commit to deliver, including all applicable statutory and regulatory requirements. To operationalize it, implement a repeatable “requirements determination” workflow that captures customer needs, legal obligations, acceptance criteria, and internal requirements, and retains evidence that these inputs were reviewed and approved. ¹

Key takeaways:

• Build a single intake and review step that consolidates customer, internal, and statutory/regulatory requirements into one controlled record.
• Make “defined requirements” auditable: documented acceptance criteria, version control, approvals, and change history.
• Tie requirements to delivery: design/production, purchasing/third-party controls, and final acceptance testing/verification.

“Determining the requirements for products and services” sounds simple until an audit asks you to prove that legal requirements were identified, translated into deliverable specs, and agreed before accepting an order or starting work. ISO 9001:2015 Clause 8.2.2 is explicit: when you determine requirements, you must ensure requirements are defined, including applicable statutory and regulatory requirements. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a controlled workflow problem, not a one-time document problem. You need a mechanism that consistently answers: What is being delivered, to whom, under what conditions, with what acceptance criteria, and under which legal/regulatory obligations? Then you need to prove it with artifacts that show review, approval, and traceability from requirements to execution and verification.

This page gives requirement-level implementation guidance you can deploy quickly: scope, roles, step-by-step process, evidence to retain, typical audit hangups, and a practical execution plan. It focuses on building an operational system that works across standard sales orders, custom projects, regulated products, and third-party delivered components.

Regulatory text

ISO 9001:2015 Clause 8.2.2 (excerpt): “When determining requirements for products and services, the organization shall ensure requirements are defined including applicable statutory and regulatory requirements.” ¹

Operator meaning: Before you commit to supply a product or service (quote acceptance, contract signature, order confirmation, project kickoff), you must define the requirements set. That set must include (1) customer-stated requirements, (2) requirements you deem necessary, and (3) applicable statutory and regulatory requirements. Your QMS must make this repeatable and auditable. ¹

Plain-English interpretation (what an auditor expects)

An auditor will test whether you:

• Consistently capture requirements for each product/service engagement (not just for “big” projects).
• Identify legal/regulatory obligations that apply to what you sell, where you sell it, and how you deliver it.
• Translate requirements into measurable acceptance criteria (what “done” means).
• Control changes when requirements evolve and show re-approval where needed.
• Can trace key requirements into downstream activities (design, production/service delivery, purchasing, and verification/validation).

If you cannot show a defined requirements record (even a lightweight one) for a sample of orders/projects, this clause is usually written up as a systemic process gap.

Who it applies to (entity and operational context)

Entity types: Any organization operating an ISO 9001:2015 quality management system, including manufacturers, software/service providers, healthcare suppliers, professional services firms, and internal shared services groups that certify to ISO 9001. ¹

Operational contexts where this clause “bites”:

• High-mix sales: Many SKUs or service packages with different terms and obligations.
• Custom work: Engineering-to-order, implementation projects, managed services, professional services statements of work.
• Regulated offerings: Products or services subject to statutory/regulatory controls in any jurisdiction where you operate or sell.
• Third-party dependencies: Where a third party provides materials, components, hosting, logistics, or subcontracted services that affect compliance or acceptance.

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

Use the steps below as your minimum viable operating procedure. Keep it simple, but make it controlled.

1) Define the trigger and scope for “requirements determination”

Decide what events require a requirements record:

• New customer/order
• Renewal with changed scope
• New product/service introduction
• Material change in delivery model, jurisdiction, or third-party reliance

Control point: No acceptance/confirmation until the requirements record is complete or formally waived under a defined exception process.

2) Create a standard “Requirements Determination Record” template

At minimum, include:

• Customer name, offering, jurisdiction(s), delivery location(s)
• Customer requirements (contract/SOW, specs, SLAs, statements in emails if relevant)
• Organization-required requirements (internal standards, security baseline, service constraints)
• Statutory/regulatory requirements (identified and mapped to concrete deliverables)
• Acceptance criteria and how they’ll be verified (test, inspection, review, service report, sign-off)
• Assumptions, exclusions, dependencies
• Required competencies, tools, and third-party inputs
• Approvals (Sales/Account Owner, Delivery Owner, Quality/Compliance where needed)
• Version control and change log

Practical tip: If you don’t already have a controlled document system, use a single workflow tool with locked fields, required approvals, and an immutable audit trail. Daydream can act as the system of record for requirement intake, routing, approvals, and evidence retention without forcing teams into spreadsheets.

3) Build a regulatory applicability check (lightweight, but mandatory)

ISO 9001 does not tell you which laws apply; it requires you to ensure applicable statutory and regulatory requirements are included in the defined requirements. ¹

Implement a checklist that forces the right questions:

• Where is the product made and shipped? Where is the service delivered?
• Who is the customer (sector constraints)? Any restricted end uses?
• What data is handled? Any safety-critical or compliance-critical attributes?
• What third parties are involved and where do they operate?

Output: A short “regulatory applicability note” that either (a) lists applicable obligations and how they are addressed, or (b) documents that none were identified for that specific engagement and why.

4) Convert requirements into measurable acceptance criteria

Auditors look for “defined” requirements that are testable. Avoid vague statements like “high quality” or “secure.”

• For products: specs, drawings, tolerances, labeling, packaging, inspection plan.
• For services: deliverables list, service levels, response times, reporting, completion criteria, customer acceptance mechanism.

Control point: Each key requirement has an associated verification method (review, inspection, test, sign-off, service report).

5) Perform a requirements review and secure approval before commitment

Route the record for review based on risk:

• Low-risk standard orders: manager approval + automated checks.
• Regulated/high-risk: Quality/Compliance approval required.
• Third-party-heavy: Purchasing/Supplier Management review required.

Evidence: Dated approvals and decision rationale.

6) Flow requirements downstream to execution (don’t let it stop at intake)

Connect the requirements record to:

• Work instructions / project plan
• Purchasing requirements for third parties (specs, compliance clauses, acceptance requirements)
• Test/inspection/verification plans
• Customer-facing acceptance documents

This is where many programs fail: they “capture” requirements but do not operationalize them.

7) Control changes (scope creep is an ISO 9001 audit magnet)

Define what constitutes a “material change” requiring re-review:

• Spec change, delivery model change, regulatory scope change, location change, third-party substitution, acceptance criteria change

Artifacts: Change request, impact assessment, updated requirements version, re-approval, customer communication where relevant.

Required evidence and artifacts to retain

Keep these in a controlled repository with retention aligned to your QMS policy:

• Requirements Determination Record ¹
• Contract/SOW/PO and any referenced specs
• Regulatory applicability note (even if “none identified” with rationale)
• Acceptance criteria and verification plan
• Approvals and timestamps (workflow audit trail)
• Change log and re-approvals
• Evidence of verification/acceptance (inspection reports, test results, service completion report, customer sign-off)
• Third-party requirements passed down (PO requirements, quality clauses, supplier specs) where third parties affect conformity

Common exam/audit questions and hangups

Expect these during certification audits:

• “Show me how you ensure statutory and regulatory requirements are identified for this order.”
• “Where are acceptance criteria defined, and how do you verify them?”
• “What happens when the customer changes scope midstream?”
• “How do you ensure third parties meet requirements you committed to?”
• “Show a sample trail from requirements to delivery evidence.”

Common hangup: Teams rely on tribal knowledge (“we always do it this way”). ISO auditors ask for objective evidence that the organization defined requirements for the specific sample.

Frequent implementation mistakes (and how to avoid them)

1. Treating requirements as a sales document only.
   Fix: Make Delivery/Operations co-own acceptance criteria and verification methods.

2. “Regulatory requirements” handled informally.
   Fix: Add a mandatory applicability step and capture the output in the record. ¹

3. Vague acceptance criteria.
   Fix: Require a verification method per key requirement. If you can’t test it, rewrite it.

4. No change control.
   Fix: Add a change trigger list and enforce re-approval for material changes.

5. Third-party requirements not flowed down.
   Fix: Purchasing and Supplier Management must receive the defined requirements needed for conformity, then bind them contractually and verify on receipt/service completion.

Enforcement context and risk implications

ISO 9001 is a certifiable standard, not a regulator, so “enforcement” typically shows up as:

• Nonconformities during external audits (major/minor), surveillance findings, and certification risk.
• Customer disputes where unclear requirements produce rework, rejected deliverables, or contract conflict.
• Regulatory exposure if statutory/regulatory obligations exist but were not identified and built into delivery requirements. Clause 8.2.2 squarely places this responsibility inside the requirements determination step. ¹

Practical 30/60/90-day execution plan

First 30 days: Stand up the minimum viable process

• Inventory where requirements currently live (contracts, emails, tickets, ERP notes).
• Create the Requirements Determination Record template with mandatory fields for statutory/regulatory applicability. ¹
• Define triggers and a “no acceptance before review” rule for a limited scope (pick one business line).
• Pilot a simple approval workflow with clear roles (Sales, Delivery, Quality/Compliance).

Next 60 days: Make it auditable and scalable

• Add acceptance criteria + verification method requirements to the template.
• Implement change control: versioning, change requests, re-approval triggers.
• Train Sales and Delivery on writing testable requirements and documenting assumptions.
• Start sampling completed engagements to confirm the record exists and is complete.

Next 90 days: Integrate and harden

• Link requirements records to downstream execution artifacts (project plans, inspection/test reports, customer acceptance).
• Extend to additional product/service lines and higher-risk deal types.
• Add third-party flowdown checks where suppliers/subcontractors affect conformity.
• Prepare an “audit ready” package: a curated set of completed examples with full traceability from requirements to acceptance evidence.

Frequently Asked Questions

Do we need a separate requirements record for every small order?

You need defined requirements for the work you accept, but you can scale the format. For standard catalog items, a controlled configuration + order confirmation can serve as the record if statutory/regulatory applicability is still addressed. ¹

What counts as “statutory and regulatory requirements” under ISO 9001 Clause 8.2.2?

It means any applicable legal or regulatory obligations that affect the product/service requirements for the specific engagement or offering. Your job is to identify what applies and ensure it becomes part of the defined requirements before commitment. ¹

Who should approve the requirements before we accept an order?

Assign approval based on risk and complexity. At minimum, the delivery owner should confirm acceptance criteria and feasibility, and Quality/Compliance should approve where statutory/regulatory requirements apply or where your QMS requires escalation. ¹

How do we handle agile delivery where requirements evolve?

Define baseline requirements at kickoff (scope, constraints, applicable statutory/regulatory obligations, and acceptance mechanism), then control changes through a documented backlog change process with versioning and re-approval triggers for material changes. ¹

Our statutory/regulatory obligations are managed by Legal. Is that enough?

Legal input helps, but ISO 9001 expects the organization to ensure applicable obligations are included in defined requirements for the product/service being delivered. You still need an operational record that shows how Legal guidance was applied to the specific engagement. ¹

What’s the simplest way to make this audit-proof without slowing Sales?

Use a tiered workflow: auto-approved paths for standard, low-risk offerings with pre-mapped requirements, and routed review for non-standard or regulated deals. A system like Daydream can enforce required fields, capture approvals, and preserve an audit trail while keeping intake lightweight.

Footnotes

1. ISO 9001:2015 Quality management systems — Requirements