ISO 9001 clause 4.2: decide whose requirements the QMS addresses

What clause 4.2 requires in practice

Clause 4.2 asks the organisation to make three decisions about the people and bodies that have a stake in its system. First, identify which interested parties are relevant to the quality management system. Second, work out the requirements those parties have that matter. Third, choose which of those requirements the system will address. The organisation then monitors and reviews information about the parties and their requirements, so the decisions stay current.

A note adds that relevant parties can have requirements linked to climate change. The clause does not impose a list of parties or a format. Customers will almost always be relevant, and regulators, providers, owners and employees may be, depending on the business.

The outputs are a reasoned view of who matters, what they need or expect, and where the system responds, which then feeds scope, planning and operational control.

Separate a party from a requirement

“Customers” is a category, not a requirement. A specified reporting format, delivery condition or competence expectation gives the team something concrete to evaluate. Similarly, naming a regulator does not establish which obligations apply. The organisation needs appropriate access to the underlying information and suitable competence to interpret it.

The standard also requires which requirements will be addressed through the QMS. Some are already binding through applicable law or accepted contracts; others may be expectations that the organisation chooses to adopt. Do not portray an obligation as optional simply because management would prefer a different arrangement. Equally, an unsolicited preference does not automatically become a promise.

Make the response visible in the relevant process

After deciding what the QMS will address, connect the requirement with an owner and a practical process. A customer's material approval condition may affect purchasing and release. An employee's need for usable instructions may affect competence and documented information. The useful link is the operating response, not an extra column marked “considered.”

The clause notes that relevant interested parties can have climate-related requirements. Consider those requirements on their own merits and applicability. For example, a customer may require particular continuity information or a change in product characteristics. Do not confuse that customer requirement with a universal ISO 9001 obligation to implement every environmental initiative.

Why interested-party requirements matter to the business

Customers rarely complain about requirements the business never knew about. They complain about those it overlooked: a reporting format, an approval condition, a regulator's expectation. Deciding deliberately whose requirements the system will address stops those gaps turning into lost contracts, regulatory trouble or provider disputes. It also protects the business from the opposite problem, where every stakeholder wish becomes an unplanned commitment. A clear position helps sales teams, operations and legal advisers answer consistently. For auditors and customers, it shows the organisation understands what it is accountable for and has made informed choices about how to respond.

How to implement clause 4.2

Make it practical by tying each party to something the business can act on. The clause requires a decision, so the practical test is whether sales, operations and purchasing would give the same answer about what a given customer or regulator requires. Keep the record short and current.

1. List the parties that can affect or be affected by delivery, and keep only those with a real link to the system.
2. For each, gather the actual requirements from contracts, specifications, regulations and conversations.
3. Sort each requirement into a binding obligation, an expectation the business adopts, or something it will not take on.
4. Record the decision and its reason so sales and operations give the same answer.
5. Name an owner and a process where each addressed requirement will be handled, such as purchasing or release.
6. Set a trigger for review, such as a new customer, a changed regulation or a provider change.

Evidence an auditor expects for clause 4.2

The auditor wants to see that requirements have been identified, decided and connected to operations.

• Records of relevant parties and their requirements, drawn from contracts, specifications or direct enquiry.
• Decisions showing which requirements the system addresses, with the reasoning.
• Interviews with sales or operations staff who can describe what a specific customer or regulator requires.
• Evidence that information was reviewed after a change, such as an updated specification.
• A traceable link from one requirement to the process and owner who deals with it.

Common nonconformities with clause 4.2

Findings generally show a list that exists without influencing the work. These findings show that the exercise was treated as a list-making task, with no decision, no review and no effect on operations, which an auditor can see by asking staff about a specific customer.

• Interested parties are named, but their requirements are not identified.
• No decision is recorded on which requirements the system will address.
• Customer or regulatory requirements have changed and the information was not updated.
• Staff are unaware of a requirement the organisation accepted, so processes do not reflect it.

Illustrative manufacturing example: a customer approval condition

Illustrative BPO example: competing expectations

A hypothetical BPO team serves a customer that wants shorter handling times while requiring complete verification of account-change requests. Employees report that the current target encourages rushed checks. Both customer requirements and the workforce's operational feedback are relevant to whether the service can meet its intended quality results.

Management examines the actual contract, distinguishes the mandatory verification steps from the desired speed improvement and reviews the target with the customer owner. It does not quietly remove checks to satisfy one metric. The resulting decision may change staffing, workflow or an agreed target. Records explain the requirements considered and the authorised resolution, rather than declaring all stakeholder wishes simultaneously satisfied.

Keep the information current

Clause 4.2 requires monitoring and review of information about relevant parties and their requirements. Changes in ownership, service scope, customer contracts or provider arrangements can alter the picture. Set review responsibilities at the places where such changes are first noticed, then communicate significant effects to the QMS owner.

No named stakeholder register or fixed review interval is prescribed by this clause. A proportionate method might use contract reviews, regulatory monitoring and management discussions together. If a register is used, avoid making it the only evidence. An auditor may follow one requirement into operating instructions, acceptance criteria and performance evaluation to see whether the decision actually influenced work.

Typical failures are vague entries, uncontrolled copies of customer specifications and requirements assigned to someone without authority over the affected process. Another is assuming that stakeholder relevance never changes. Test a recent new contract or service change: can the responsible team explain what changed and how the QMS responded?