Determining the scope of the quality management system

To meet ISO 9001:2015 Clause 4.3, you must define and document the boundaries and applicability of your quality management system (QMS) so it’s clear which sites, functions, processes, products/services, and outsourced activities are covered, and why. Then you must keep that scope consistent with your context and obligations, and make it available as documented information. 1

Key takeaways:

  • Your QMS scope is a boundary statement plus an applicability rationale, not a marketing description.
  • The scope must reflect internal/external issues, interested party requirements, and your products/services. 1
  • Auditors expect tight alignment between scope, process map, outsourced processes, and any “non-applicable” requirements.

Clause 4.3 is a fast fail area in certification audits because it looks simple and teams treat it as a paragraph on the website. Auditors read your scope as a binding statement: it defines what the QMS controls, what it does not control, and how you justify those boundaries. If the scope is vague, overly broad, or contradicted by your org chart, process map, contracts, or customer commitments, you create avoidable nonconformities and a messy corrective action cycle.

Operationalizing this requirement means making the QMS “border” explicit: which legal entity or business unit is in scope, which locations are included, which products and services are covered, and which supporting functions and outsourced processes are part of the system. You also need a practical method to keep the scope current when the business changes (new sites, acquisitions, product lines, third parties, or reorganizations).

This page gives you requirement-level implementation guidance you can apply immediately: who should own the scope decision, what to document, what evidence to retain, common audit traps, and a pragmatic execution plan that fits how compliance and quality teams actually work.

Regulatory text

ISO 9001:2015 Clause 4.3: “The organization shall determine the boundaries and applicability of the quality management system to establish its scope.” 1

What the operator must do

  • Determine boundaries: state what parts of the organization the QMS covers (entities, sites, departments, processes).
  • Determine applicability: confirm the QMS meaningfully applies to the products/services you provide and the way you provide them, including relevant outsourced processes.
  • Establish the scope: produce a clear scope statement and maintain it as controlled documented information that matches reality and your obligations. 1

Plain-English interpretation (what Clause 4.3 is really asking)

Write down exactly what your QMS covers and why, in a way an auditor can test. If a location, function, product line, or third-party-delivered activity affects quality outcomes for in-scope products/services, it usually belongs in scope or must be explicitly addressed as an outsourced process within scope. If something is excluded, you need a defensible rationale and you cannot exclude to dodge responsibilities that still affect customer requirements.

Think of the scope as a control boundary:

  • Inside the boundary: you run processes under QMS control (procedures, training, records, internal audit coverage, CAPA, management review inputs).
  • Outside the boundary: not governed by your QMS, but this creates audit scrutiny if it touches customer requirements or the conformity of your outputs.

Who it applies to

Entity types

  • Any organization implementing or certifying an ISO 9001:2015 QMS. 1

Operational contexts where scope decisions matter most

  • Multi-site operations (HQ plus satellite locations, labs, warehouses, service centers).
  • Mixed portfolios (regulated + non-regulated lines, bespoke services + standard products).
  • Complex delivery models (outsourced manufacturing, outsourced service delivery, subcontractors, cloud/SaaS providers supporting delivery).
  • Corporate groups with multiple legal entities where contracts and invoicing do not match operational reality.

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

1) Name the “scope owner” and decision forum

Assign accountability to a single role (often Quality Director with CCO/GRC input if obligations are contract-heavy). Use a defined approval body (management review or an equivalent leadership forum) so scope changes are controlled, not ad hoc.

Output

  • Scope owner named in a responsibility matrix.
  • Approval mechanism defined (who signs, how changes are reviewed).

2) Inventory what could be “in scope”

Build a simple inventory table covering:

  • Legal entities / business units
  • Physical sites and remote work arrangements
  • Core processes (sales through delivery, design/development if applicable, purchasing, production/service operations, inspection/testing, customer support)
  • Products and services delivered to customers
  • Supporting functions that affect conformity (training, document control, IT systems that run production/service, calibration, etc.)
  • Outsourced processes and critical third parties (contract manufacturers, logistics, field service subcontractors)

Tip from audits: If you can’t trace a site or team on the org chart to the scope statement, the scope is too fuzzy.

3) Evaluate boundaries using three required lenses

Clause 4.3 expects your scope to reflect:

  • Internal and external issues
  • Interested party requirements
  • Products and services 1

Turn those into a short, testable rationale:

  • Internal/external issues: complexity, geography, regulatory environment, delivery model, growth/acquisition changes.
  • Interested parties: customers, regulators (if applicable), owners, employees, key third parties.
  • Products/services: what you actually deliver that the QMS claims to control.

Output

  • A “scope rationale” paragraph or table mapping these lenses to boundary choices.

4) Draft a scope statement an auditor can verify

A strong scope statement includes:

  • What you do (products/services)
  • Where you do it (sites/locations)
  • Who is covered (entity/business unit)
  • Key delivery boundaries (e.g., “including design,” “excluding installation,” only if true and defensible)

Examples (adapt, don’t copy blindly)

  • “Provision of [service] from [Site A] and [Site B], including customer onboarding, service delivery, and support.”
  • “Design and manufacture of [product category] at [plant], including purchasing and supplier management for components affecting product conformity.”

Avoid:

  • “All company activities” (too broad to support)
  • “Quality management for excellence” (not auditable)
  • Site lists that omit a warehouse or lab that touches in-scope product.

5) Align the scope to your process map and outsourced processes

Auditors reconcile your scope against:

  • Process map / interaction of processes
  • Purchasing and supplier controls
  • Contracts/SOWs with third parties that perform parts of delivery

Do a traceability check:

  • Each in-scope product/service must map to end-to-end processes under QMS control.
  • Each outsourced step that affects conformity must appear in your process map and supplier controls, even if performed by a third party.

Practical check: If a third party performs the final inspection, packing, software deployment, calibration, or field service, you need to show how your QMS controls that outsourced process.

6) Decide and document any “non-applicable” requirements carefully

Even though Clause 4.3 is about scope, auditors often test how you treat requirements you claim don’t apply. Your exclusions must not undermine your ability to deliver conforming products/services or meet customer requirements.

Output

  • A short applicability matrix: ISO clause vs. applicable (Y/N) with rationale for any “N”.

7) Control the scope as documented information and keep it current

Treat the scope like a controlled document:

  • Version control, owner, approval date
  • Change triggers: new site, new service line, acquisition, outsourcing changes, major org restructure

Set a cadence to review scope during management review, plus an “event-driven” update rule when material changes occur.

Required evidence and artifacts to retain

Keep artifacts tight and audit-friendly:

  • QMS Scope Statement (controlled document)
  • Scope rationale tied to internal/external issues, interested parties, and products/services 1
  • Site list and function list mapped to scope
  • Product/service catalogue (at least the in-scope offerings)
  • Process map / interaction of processes showing coverage and outsourced processes
  • Outsourced process register (third parties, what they do, how you control it)
  • Applicability matrix for any requirements claimed non-applicable
  • Change log for scope updates and approval evidence (meeting minutes, management review outputs)

Common exam/audit questions and hangups

Expect auditors to ask:

  • “Which sites are included, and where is that stated?”
  • “Does the scope include design/development? Show me where design controls exist.”
  • “You use a third party for [manufacturing/logistics/service]. How is that controlled within the QMS?”
  • “Your scope says ‘manufacture’ but your operation is assembly plus outsourced fabrication. Explain the boundary.”
  • “Show how the scope reflects interested party requirements.” 1
  • “What changed since last year and did you update scope?”

Hangups that cause nonconformities:

  • Scope claims coverage that internal audit never touches.
  • A “remote” or shared-service function materially affects quality but is omitted from scope.
  • Outsourced processes exist in practice but are not recognized as part of QMS control.

Frequent implementation mistakes and how to avoid them

  1. Writing a scope statement that’s promotional

    • Fix: Use auditable nouns and verbs: design, manufacture, test, distribute, service, support.
  2. Confusing “organization” with “legal entity”

    • Fix: Specify entity/business unit explicitly, especially in corporate groups.
  3. Excluding a location that touches product conformity

    • Fix: If the warehouse labels, stores, or ships in-scope product, treat it as in scope or document controls that make it effectively part of the system.
  4. Ignoring third parties in the scope boundary

    • Fix: Keep the scope boundary internal, but explicitly cover outsourced processes via purchasing controls, acceptance criteria, monitoring, and records.
  5. No mechanism to keep scope current

    • Fix: Add scope review to management review inputs and define event-based triggers for updates.

Enforcement context and risk implications

ISO 9001 is a standard used for certification rather than a regulator-enforced law in most contexts. The practical “enforcement” is certification audit risk: a weak or misleading scope leads to nonconformities, increased surveillance scrutiny, or limitations on what your certificate can credibly claim. Commercial risk follows quickly: customers often rely on the scope to decide whether your certification covers the product/service they are buying.

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

  • Assign scope owner and approvers.
  • Build the inventory of entities, sites, products/services, processes, and key third parties.
  • Draft the scope statement and initial scope rationale.
  • Identify obvious mismatches (e.g., missing sites, unclear service boundaries).

Days 31–60 (prove alignment and close gaps)

  • Map scope to process interaction map.
  • Build outsourced process register and confirm supplier controls exist for each outsourced step.
  • Create an applicability matrix for any “non-applicable” requirements with rationale.
  • Run an internal “scope audit” walkthrough: pick one product/service and trace end-to-end delivery against the scope and process map.

Days 61–90 (institutionalize change control)

  • Add scope review to management review agenda and outputs.
  • Add event-driven change triggers tied to business change management (new site, new third party, acquisition, new product/service).
  • Train process owners on what “in scope” means for records, audits, CAPA, and change control.
  • If you use Daydream for third-party risk workflows, connect the outsourced process register to your third-party inventory so scope changes automatically flag needed due diligence updates.

Frequently Asked Questions

Do we need a separate QMS scope for each site?

Not necessarily. You can have a single scope statement that clearly lists included sites and the activities performed at each, as long as it stays auditable and consistent with how work is actually done.

Can we exclude a department like HR or IT from the QMS scope?

You can keep the scope focused, but if HR or IT activities affect competence, training, or systems used to deliver in-scope products/services, auditors may expect those controls to be addressed within the QMS boundary or via defined interfaces.

How do outsourced processes affect the scope?

Outsourcing does not remove responsibility for conformity. If a third party performs a step that affects product/service conformity, you must show QMS control over that outsourced process through defined requirements, monitoring, acceptance criteria, and records.

What’s the difference between “scope” and “process map”?

The scope is the boundary statement of what is covered. The process map is the operational proof: it shows the processes and interactions that implement the scope.

Our scope changed after an acquisition. Do we need to update documented scope immediately?

Update it as part of your change control as soon as the acquisition affects sites, processes, products/services, or outsourced steps tied to your QMS claims. Delayed updates create audit findings because the scope no longer matches reality.

How specific should the scope be about products and services?

Specific enough that a customer or auditor can tell whether a particular offering is covered. Broad categories are fine if they are accurate and align with your actual delivery processes and records.

Footnotes

  1. ISO 9001:2015 Quality management systems — Requirements

Frequently Asked Questions

Do we need a separate QMS scope for each site?

Not necessarily. You can have a single scope statement that clearly lists included sites and the activities performed at each, as long as it stays auditable and consistent with how work is actually done.

Can we exclude a department like HR or IT from the QMS scope?

You can keep the scope focused, but if HR or IT activities affect competence, training, or systems used to deliver in-scope products/services, auditors may expect those controls to be addressed within the QMS boundary or via defined interfaces.

How do outsourced processes affect the scope?

Outsourcing does not remove responsibility for conformity. If a third party performs a step that affects product/service conformity, you must show QMS control over that outsourced process through defined requirements, monitoring, acceptance criteria, and records.

What’s the difference between “scope” and “process map”?

The scope is the boundary statement of what is covered. The process map is the operational proof: it shows the processes and interactions that implement the scope.

Our scope changed after an acquisition. Do we need to update documented scope immediately?

Update it as part of your change control as soon as the acquisition affects sites, processes, products/services, or outsourced steps tied to your QMS claims. Delayed updates create audit findings because the scope no longer matches reality.

How specific should the scope be about products and services?

Specific enough that a customer or auditor can tell whether a particular offering is covered. Broad categories are fine if they are accurate and align with your actual delivery processes and records.

Authoritative Sources

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream
Determining the scope of the quality management system | Daydream