Clause 8 is where the QMS enters direct value creation. Part 1 of Clause 8 covers the front-end operating spine: operational planning, customer communication, contract review, requirement definition, and design and development controls. These are the points where weak assumptions are most expensive because errors are locked into the system before production even starts.
Organizations that perform well under Clause 8 Part 1 are disciplined before commitment. They define acceptance criteria early, capture explicit and implicit customer requirements, verify capability before saying yes, separate verification from validation, and control operational changes before they create nonconforming output.
Visual Summary
Use the Clause 8 Part 1 visual for a quick review of planning discipline, requirement capture, contract acceptance, design controls, and change review.
Jump to Guide Sections
1. Why Clause 8 Part 1 Is the Front-End Control System
The first half of Clause 8 controls the most expensive decision points in the QMS. Once an order is accepted, a design is released, or a plan is pushed into production, the organization inherits the cost of any weak assumptions hidden in that decision. This clause is therefore less about paperwork and more about disciplined pre-commitment judgment.
What Clause 8 Part 1 Prevents
Unclear acceptance criteria, requirement gaps, premature customer commitments, uncontrolled design release, and last-minute operational changes that create quality escapes.
What Clause 8 Part 1 Creates
A repeatable way to decide what will be done, what the customer truly needs, whether the organization can deliver, and how design output will be proven before release.
2. Clause 8.1: Operational Planning and Control
Clause 8.1 requires the organization to plan, implement, and control the processes needed to meet product and service requirements. This includes establishing criteria for the processes and for acceptance of outputs, determining required resources, implementing control of processes in accordance with those criteria, and retaining appropriate documented information.
| Planning Element | Practical Meaning | Typical Evidence |
|---|---|---|
| Process criteria | Define how the work will be performed and what conditions must be true before the work proceeds. | Control plans, routings, travelers, standard work, release gates, inspection plans. |
| Acceptance criteria | Define what good looks like before production or service execution begins. | Specifications, drawings, tolerance requirements, checklists, acceptance protocols. |
| Resource planning | Confirm people, machines, tools, software, fixtures, and measurement capability are available. | Capacity reviews, staffing plans, tooling readiness, calibration status, ERP readiness. |
| Control of planned changes | Review the quality effect of planned or unplanned changes before they alter execution. | Engineering change review, deviation approvals, risk updates, revised instructions. |
3. Clause 8.2: Requirements for Products and Services
Clause 8.2 governs how the organization communicates with customers, determines requirements, reviews those requirements before commitment, and ensures changes are controlled. The organization must capture not only what is written in the quote package or drawing, but also the implied, statutory, regulatory, and usage-related requirements that shape conformity.
| Requirement Type | Examples | Why Misses Are Dangerous |
|---|---|---|
| Stated customer requirements | Drawings, specifications, statements of work, purchase orders, packaging instructions. | These define the explicit basis for acceptance and are often the most visible audit trail. |
| Unstated but necessary requirements | Fit, function, usability, field environment, installation needs, service assumptions. | Products can conform to paperwork but still fail the actual use case. |
| Statutory and regulatory requirements | Safety, labeling, environmental, export, industry-specific compliance rules. | Missing these creates legal and customer-risk exposure even if production output looks acceptable. |
| Organization-imposed commitments | Quoted lead times, warranty terms, performance guarantees, service-level promises. | The organization becomes accountable for what it promises, not just what the customer wrote. |
4. Clause 8.2.3: Review of Requirements Before Commitment
This is the pre-commitment gate. Before the organization accepts a customer order or enters a contract, it must review whether requirements are defined, whether differences from previous expressions are resolved, and whether it can actually meet the requirements.
What Should Be Asked
- Are all technical, commercial, and compliance requirements understood?
- Do we have process capability, material availability, tooling, and measurement control?
- Are lead time and volume expectations realistic?
- Have differences from prior revisions or verbal conversations been reconciled?
What Often Goes Wrong
- Sales accepts the order before operations confirms feasibility.
- Special characteristics or compliance obligations are missed in review.
- Old assumptions carry forward after a drawing or revision change.
- Capacity constraints are treated as scheduling problems instead of contract-review inputs.
5. Clause 8.3: Design and Development Controls
Clause 8.3 applies when the organization is responsible for design and development. The standard expects planned design stages, review, verification, validation, control of design inputs and outputs, and management of subsequent design changes. The goal is not document volume; it is design discipline.
| Control Point | Purpose | Typical Evidence |
|---|---|---|
| Design inputs | Define all requirements the design must satisfy. | Customer requirements, regulatory needs, prior lessons learned, interface definitions, functional expectations. |
| Design reviews | Check progress, expose risks, and align stakeholders before release. | Cross-functional review minutes, action lists, gate decisions, unresolved issue logs. |
| Design verification | Prove the design output matches the design input. | Calculations, drawing checks, code review, spec traceability, test evidence against requirements. |
| Design validation | Prove the design is fit for actual intended use. | Prototype use tests, pilot trials, customer trials, simulated-use evidence, field evaluation. |
| Design changes | Control the effect of revisions after release. | Change review records, risk review, updated verification/validation, release approvals. |
6. Verification vs. Validation
This distinction causes confusion in many QMS implementations. Verification asks whether the organization built the design right according to specified requirements. Validation asks whether the organization built the right design for the real user and real use condition.
| Question | Verification | Validation |
|---|---|---|
| Core question | Did we build the design right? | Did we build the right design? |
| Primary reference | Design input requirements. | Intended use and user need. |
| Common methods | Reviews, calculations, requirement checks, engineering analysis, inspection. | Pilot use, field evaluation, user trials, environmental simulation, functional demonstration in context. |
| Common failure | Requirements are met technically, but some input was incomplete or wrong. | The product works in test conditions but fails in real customer use conditions. |
7. Controlling Operational Change Across Clause 8
Operational changes connect Clause 8.1 and Clause 8.3.6. Whether the change is planned or emerges in response to a disruption, the organization has to assess its quality impact before letting the change flow through the process. That includes design changes, supplier changes, route changes, inspection changes, and revised release assumptions.
High-Risk Change Examples
- Substituting a material or component after sourcing pressure.
- Changing a process sequence or machine setting outside the validated window.
- Accepting a rush order that bypasses the normal requirement-review gate.
- Releasing a design revision without revisiting verification or validation impacts.
Strong Change Review Controls
- Defined approval roles.
- Impact review on quality, delivery, and compliance.
- Updated documented information and training.
- Risk refresh and post-change verification.
8. Quick Reference: Clause 8 Part 1 Audit Readiness
Operational Planning Checks
- Process criteria and acceptance criteria are defined before execution.
- Required resources are confirmed before release.
- Operational plans are retained in a usable form.
- Planned and unplanned changes are reviewed for quality impact.
Customer Requirement Checks
- Customer communication channels are clear and controlled.
- Stated, unstated, statutory, and organization-imposed requirements are captured.
- Review-before-commitment proves capability before acceptance.
- Requirement changes are resolved and communicated downstream.
Design-Control Checks
- Design inputs are complete and controlled.
- Design reviews are cross-functional and action-driven.
- Verification and validation are defined distinctly.
- Design changes trigger review, evidence refresh, and controlled release.
Management Questions
- How do you know you have captured the full requirement spectrum before commitment?
- What evidence proves you were capable of meeting the order when you accepted it?
- How do you distinguish verification from validation in your development work?
- How are operational or design changes reviewed before they affect shipped product?