Clause 8 as the QMS Operational Core
Clause 8 is the largest and most operationally significant clause in ISO 9001. It is where quality is actually produced or failed. Everything in Clauses 4 through 7 is preparation for Clause 8. Auditors spend the majority of their time in Clause 8, examining how the organization actually prevents or detects nonconformity. The operational controls defined in Clause 8 are what prevent nonconformity from reaching customers.
Clause 8.1: Operational Planning and Control
Clause 8.1 is the overarching operational requirement. It requires the organization to plan, implement, control, and maintain processes needed to meet product and service requirements and to achieve customer satisfaction. To do this, organizations must establish criteria for process operation (how well must the process work), ensure necessary resources are available, define documented information for process control, manage planned changes to processes in a controlled manner, and control externally provided processes (covered in detail in Clause 8.4).
The operational framework established in Clause 8.1 is then elaborated in Clauses 8.2 through 8.7, which define specific operational activities: customer requirements determination and review, design and development (where applicable), control of external providers, production and service control, management of nonconforming output, and post-delivery activities.
Clause 8.2: Customer Requirements
Clause 8.2 requires a complete customer requirements cycle with four specific sub-clauses. First, customer communication (Clause 8.2.1) ensures that all customer communication channels are managed — inquiries, orders, feedback, and complaints. Second, requirements determination (Clause 8.2.2) ensures that all requirements are captured — stated, unstated, and regulatory. Third, requirements review (Clause 8.2.3) ensures that requirements are reviewed before commitment to supply. Fourth, change management (Clause 8.2.4) ensures that changes to requirements are captured and communicated to all affected parties.
| Sub-Clause | Requirement | Key Question | Common Failure |
|---|---|---|---|
| 8.2.1 Customer communication | Communicate about products/services, inquiries, feedback, complaints | Are all customer communication channels managed? | Informal communication not captured or documented |
| 8.2.2 Requirements determination | Determine all requirements: specified, not stated, statutory/regulatory | Are unstated requirements identified? | Only documented requirements captured; unstated needs missed |
| 8.2.3 Requirements review | Review requirements before committing to supply | Is review documented before commitment? | Verbal commitments without review record or signature |
| 8.2.4 Changes to requirements | Ensure amended information captured when requirements change | Are all changes to requirements captured and communicated? | Scope creep without documented change control |
Understanding "Unstated" Customer Requirements
Clause 8.2.2 distinguishes between stated requirements (explicitly communicated by the customer) and unstated requirements (necessary for the intended use but not explicitly stated). For example, a customer buying a software system expects it to work on their hardware platform even if they did not state this as a requirement. A customer buying a medical device expects it to be safe to use and compatible with the intended patient population even if they did not explicitly require these things. Identifying and documenting unstated requirements is the purpose of the requirements review procedure.
The procedure for Clause 8.2.2 typically requires that the person reviewing customer requirements asks clarifying questions and documents assumptions about unstated requirements. This is why the requirements review record (Clause 8.2.3) is so important — it is the mechanism for making unstated requirements explicit and visible.
Clause 8.3: Design and Development
Clause 8.3 applies when the organization designs or develops products or services. The standard permits exclusion of Clause 8.3 only when the organization performs no design or development activities — for example, a company that sells standard off-the-shelf products without modification can exclude Clause 8.3. However, many organizations that believe Clause 8.3 does not apply actually do design work and should include it.
Clause 8.3 defines six design and development activities: planning (establishing design objectives, timeframe, responsibility), inputs (documenting design requirements), controls (conducting systematic design reviews, verification, and validation at appropriate stages), outputs (documenting design results and requirements), changes (controlling and approving design changes), and verification and validation (confirming the design meets requirements and the product meets customer needs).
| Design & Development Activity | Requirement | Evidence |
|---|---|---|
| Design inputs | Document requirements including functional, performance, regulatory, and use requirements | Design brief, requirements specification with customer sign-off |
| Design controls | Conduct systematic reviews at appropriate stages to assess whether design meets input requirements | Design review meeting records with attendees, date, decisions, sign-offs |
| Verification | Confirm design outputs meet input requirements | Test reports, inspection records, design verification matrix |
| Validation | Confirm product/service meets specified use requirements and customer needs | User acceptance testing, field trial records, prototype testing results |
| Design changes | Control and approve changes to design during development | Change control records, re-verification/validation for changes |
| Design documentation | Retain documented information of design process and results | Design file including specifications, drawings, analysis, review records |
When Design and Development Applies to Services
A common misconception is that Clause 8.3 applies only to physical product design. Service organizations frequently exclude Clause 8.3 incorrectly. The question is not "are we designing a physical product?" but "are we designing a new service offering that requires design inputs, planning, verification, and validation?" If you design a custom cloud solution for a specific client, that is design and development. If you design a new training program, that is design and development. If you deliver an established service offering without modification, that is not design and development.
Indonesian technology companies (software development, custom systems integration), consulting firms that design service solutions, and organizations that create new offerings for specific customer requirements must apply Clause 8.3. It is one of the most commonly incorrectly excluded clauses in certification audits.
The Requirements Review Record
The requirements review record (Clause 8.2.3 documented information) is critical audit evidence. The record must evidence that: all customer requirements (stated and unstated) have been identified and documented, any unstated requirements necessary for intended use have been clarified and documented, regulatory requirements applicable to the product or service have been identified and incorporated, the organization has confirmed it can meet the requirements, and the customer has accepted the requirements review.
The record does not need to be complex. A one-page requirements review form completed for each order and signed by both the customer and the responsible organization representative is sufficient. Electronic and paper records are equally acceptable, as long as the records are systematic and retained. Multi-party contracts should include a documented requirements review step before execution.
| KEY IDEA | The most expensive quality failures happen when organizations commit to customer requirements they have not fully understood or that conflict with their capabilities. Clause 8.2.3 (review of requirements before commitment) is the primary prevention mechanism. A 30-minute structured requirements review before contract signing is worth far more than corrective action after delivery. The requirements review is not a compliance formality — it is a risk management tool. |
| IMPORTANT | Clause 8.3 applies to any design or development activity, not just physical product design. Indonesian software development companies, consulting firms that design service solutions, and any organization that creates new products or services for specific customer requirements must apply Clause 8.3. The most common exclusion error is technology companies claiming Clause 8.3 does not apply when they do custom software development or system integration. If requirements are analyzed, a design is created, and a solution is built to meet those requirements, that is design and development. |
| BITLION INSIGHT | The requirements review procedure is one of the first things a Stage 2 auditor will test — they will select a sample of recent contracts or orders and trace the requirements review record. Organizations that handle requirements verbally or by email without a structured review record generate findings here. A simple, consistently applied requirements review template and sign-off process takes minutes to create and prevents some of the most expensive quality failures. |