ISO 9001 clause 4.3: define a scope that matches your responsibility

What clause 4.3 requires in practice

Clause 4.3 asks the organisation to decide where its quality management system begins and ends, and where it applies. In reaching that decision it considers the issues from 4.1, the requirements from 4.2 and its own products and services. The organisation then applies every requirement of the standard that is applicable within the scope it has set.

The scope has defined content:

• It states the types of products and services covered.
• It gives a justification for any requirement the organisation treats as not applicable.
• It is available as documented information.

There is also a limit on exclusions. Conformity can be claimed only if leaving out a requirement as not applicable has no effect on the organisation's capability or duty to make its products and services conform and to raise customer satisfaction. The output is a scope statement that matches the real operation and can be defended to customers and auditors.

Describe the real operating arrangement

Begin with what the organisation supplies and the processes needed to supply it. Consider locations, functions and interfaces that materially affect the covered products and services. A head-office purchasing team may influence quality at several sites; a central software team may control changes to a service delivered elsewhere. An organisational boundary does not make those interfaces disappear.

Use clear product and service descriptions. A vague phrase such as “all business activities” may hide uncertainty, while an excessively narrow phrase may omit a responsibility that customers reasonably associate with the service. The appropriate scope is not established by a preferred certificate wording alone. It must reflect the system actually implemented.

Justify any non-applicability

The organisation applies the requirements that are applicable within its defined QMS scope. Any requirement considered inapplicable needs a justification in the scope. Such a decision must not affect the organisation's ability or responsibility to ensure conformity of its products and services and enhance customer satisfaction.

Do not use a generic “we are a service company” justification to dismiss design, measuring resources or customer property. Examine the actual activity. A service can be designed, a digital output can need verification, and customer property can include information. The decision follows responsibility and operating facts, not industry stereotypes or a copied list of exclusions.

Why a scope matched to responsibility matters

The scope is the promise a business makes about what its system covers. If it is too wide, the organisation claims control it does not have. If it is too narrow, customers may assume protection that is not there, and a regulator or a dispute may expose the gap. A scope that follows real responsibility also helps leaders decide where to invest: shared functions, outsourced work and multi-site arrangements become visible. It affects how the organisation describes itself in tenders and certificates, so an inaccurate scope is a reputational risk. A clear, justified scope keeps conversations with customers and auditors short and accurate.

How to implement clause 4.3

Draft the scope from the work itself, then test it against the business, rather than copying wording from another organisation. Treat the wording as a statement of responsibility that customers and auditors will rely on, so it should match what the organisation genuinely does.

1. Take the outputs of the context and interested-party work and list the products and services the organisation supplies.
2. Identify the sites, functions and shared teams that materially influence those outputs, including outsourced activities that affect them.
3. Write a scope that names the types of products and services covered in plain terms.
4. Go through the standard's requirements and test each one against what the organisation really does, such as whether it designs anything or controls customer-owned items.
5. Record a justification for each requirement treated as not applicable and check that none affects conformity or satisfaction.
6. Approve the scope through top management, keep it as controlled information and revisit it when activities, sites or services change.

Illustrative software example: configuration or design?

Illustrative construction example: outsourced design

A hypothetical fit-out contractor engages external designers while committing to a completed design-and-build service. The contractor proposes a QMS scope limited to installation because drawings come from another company. That boundary would not adequately explain its retained contractual responsibility for coordinating and accepting design.

The team clarifies who determines requirements, approves design changes and accepts outputs from the external designer. It connects the resulting responsibilities with design and provider controls. The example does not mean every contractor has identical design obligations; a contractor delivering strictly to an authorised customer design may have a different arrangement that requires its own justification.

Keep the documented scope aligned with change

Growth, acquisitions, new services or a changed outsourcing model can make an earlier scope inaccurate. Review boundaries when those changes occur, and check their effect on process ownership, competence and evaluation. A business may need to revise its QMS before making broader claims about coverage.

The QMS scope and a certification body's certificate scope are related but should not be casually treated as interchangeable. The independent body determines certification based on its assessment and agreed arrangements. Avoid suggesting that every group company, site or product is covered merely because one defined system has been certified.

Evidence and common mistakes