ISO Clause 4.3: Determining Your Scope

Clause 4.3 says the organisation shall determine the boundaries and applicability of the management system to establish its scope. Read that first word again. The organisation. Not the certification body, not the auditor, not the consultant. You decide what your management system covers, and you are entitled to draw that line deliberately.

That freedom comes with a burden of proof. The scope has to be maintained as documented information, it has to state the types of products and services covered, and it has to provide justification for any requirement of the standard you determine is not applicable. Get the justification right and the conversation at audit is short. Get it wrong, or leave it vague, and you have handed the auditor an invitation to decide your scope for you.

Tilt-shift miniature of a submarine periscope casting a narrow cone of light onto one small island of activity in a vast dark ocean — A good scope is a deliberate, narrow field of view. Certifying everything costs you audit days every year, for as long as you hold the certificate.

What clause 4.3 requires

Four things, and they are more specific than most scope statements suggest:

Determine the boundaries and applicability of the management system.
Consider the external and internal issues from clause 4.1, the requirements of relevant interested parties from clause 4.2, and the products and services of the organisation.
Apply all the requirements of the standard that are applicable within that determined scope.
Maintain the scope as documented information, stating the types of products and services covered, and justifying any requirement determined to be not applicable.

Then the sentence that governs everything else: conformity to the standard may only be claimed if the requirements determined as not applicable do not affect your ability or responsibility to ensure the conformity of your products and services and the enhancement of customer satisfaction.

That is the test. Not “is it inconvenient”, not “we have never done it that way”. Does leaving it out affect your ability or responsibility to deliver conforming product and satisfied customers? If it does, you cannot leave it out and still claim conformity.

You determine the scope, not the auditor

This matters because a lot of businesses arrive at certification believing scope is something done to them. It is not. The standard puts the determination squarely with the organisation, and a well-reasoned scope should survive contact with any competent auditor.

What the auditor legitimately does is different, and worth understanding so you can tell the two apart. The auditor tests whether your determination holds up: whether the boundaries you drew match what the business actually does, whether the interested parties and issues you considered are the real ones, and whether your justifications for non-applicability stand scrutiny. That is their job, and a good auditor doing it properly is useful to you.

What an auditor should not be doing is substituting their own preference for yours where your reasoning is sound. The practical defence against that is not argument on the day. It is a scope statement written well enough that there is nothing left to argue about.

Two different documents: certificate scope and management system scope

Here is a distinction that causes a surprising amount of confusion, because the same word is doing two jobs.

The certificate scope is the line printed on your certificate by the certification body. It is deliberately short, often a single sentence, because it has to fit on a certificate and be readable by a client or a tender evaluator who knows nothing about your business. Something like: “Design, manufacture and installation of structural steel products.”

The management system scope is the documented information clause 4.3 actually requires you to maintain. It is a fuller outline of the operations covered by the system: the products and services, the sites and physical boundaries, the organisational units and functions included, the processes within the boundary, anything outsourced or externally provided, and any requirement determined not applicable together with its justification.

The two are related but they are not the same document, and they should not be. The certificate scope is a summary for an external audience. The management system scope is the working definition your system runs on, and the one that has to satisfy 4.3.

Where businesses get into trouble is treating the one-liner as the whole job. If your entire documented scope is the sentence that appears on the certificate, you have not met clause 4.3, because that sentence cannot carry the sites, the boundaries, or the justification for anything not applicable. Conversely, if your certificate scope claims more than your management system scope actually covers, you have a problem the auditor will find and a client relationship you may struggle to defend.

Write the management system scope properly and the certificate scope falls out of it as a summary. Try to work the other way around and you will always be short of something.

Boiling the ocean: the cost of over-scoping

The most common scoping mistake is not excluding too much. It is including too much.

Businesses routinely certify the whole organisation when the commercial driver was one division, one site or one service line. It feels safer and more impressive. It is neither. A larger scope means more processes to document, more people to train, more evidence to maintain and, very directly, more audit days, because certification bodies price on the size and complexity of what you have asked them to audit. You will pay for that scope every year for as long as you hold the certificate.

Worse, an oversized scope dilutes the system. The parts of the business that needed the discipline get the same thin coverage as the parts that were only ever along for the ride, and the whole thing starts to feel like overhead. That is precisely the outcome a lean management system is designed to avoid.

Before you set the boundary, ask what the scope is for. Usually it is a tender requirement, a client demand or a regulatory expectation. Read the actual wording of what is being asked. If a client requires ISO 9001 certification covering the services they buy from you, certifying those services is sufficient. Certifying everything else is a gift you are making to your certification body.

Inside your periscope: scoping deliberately

A defensible scope is narrow enough to be genuinely controlled and honest enough that nobody feels misled. Some practical tests:

Can you name the boundary in a sentence? “Design and manufacture of steel fabrication products at our Brisbane facility” is a boundary. “Quality management” is not.
Does the boundary match a real organisational unit? Sites, divisions, product lines and service streams make clean boundaries. Arbitrary carve-outs inside a single process do not.
Would a customer reading your certificate be misled? If your certificate implies more than you actually certified, you have a commercial and reputational problem regardless of what the auditor accepted.
Can you control what is inside it? You cannot meaningfully certify activities you have no authority over.
Does anything inside the boundary depend on something outside it? If so, that dependency needs managing as an externally provided process, not quietly ignored.

Non-applicability: justification is the whole game

Clause 4.3 lets you determine that a requirement is not applicable. It does not let you do so silently.

First, a terminology point that still trips people up. ISO 9001:2015 dropped the word “exclusions”, which in the 2008 version applied only to clause 7. The current language is not applicable, and it can in principle apply to any requirement, subject to the conformity test above. If your scope statement still says “exclusions to clause 7”, it is written against a standard that was withdrawn years ago.

A justification that works is specific, factual and closes the door:

Clause 8.3 Design and development is not applicable. The organisation manufactures to customer-supplied drawings and specifications and does not determine or develop product characteristics. Customer requirements are reviewed under clause 8.2 and production is controlled under clause 8.5. No design activity is undertaken by the organisation.

That gives the auditor the what, the why, and where the work is controlled instead. There is nothing left to probe.

A justification that fails looks like this:

Clause 8.3 is excluded as it is not relevant to our business.

That is an assertion, not a justification. It tells the auditor nothing, so they will go and form their own view, and you will spend the opening hours of your audit defending a position you never actually stated. Clause 8.3 design and development is the single most argued-about non-applicability, precisely because auditors carry different preconceptions about what counts as design, so it is the one most worth writing carefully.

Nothing is worse than an ambiguous scope statement

An ambiguous scope is worse than a narrow one and worse than a broad one, because it fails in every direction at once.

At audit, ambiguity invites interpretation, and the interpretation will not be yours. Commercially, a vague scope on a certificate is hard for a client to rely on, which defeats the purpose of certifying. Internally, if your own people cannot tell what is in and what is out, the system will be applied inconsistently, and that inconsistency is what surfaces as findings.

The fix is unglamorous. Write the scope statement as though a stranger will read it with no other context, because at some point one will: an auditor, a tender evaluator, a prospective client. State the products and services. State the sites. State anything determined not applicable and why. Then read it back and ask whether a reasonable person could form a different view of what you certified. If they could, it is not finished.

Two scoping decisions in practice

Both of the following are real projects, described without naming the businesses. They are worth reading together because they solve the same problem with two different mechanisms. The first draws the boundary around an organisational unit. The second draws it across the value chain, at a handover point. Neither required a single requirement of the standard to be determined not applicable, which is a distinction worth holding onto.

A subsidiary that runs on its parent’s back office

The business is a wholly owned operating subsidiary of a large listed group, in a licensed and regulated sector. It runs the systems and services that sit behind its customer-facing sites. Human resources, IT, finance and much of sales are not its own functions at all. They are shared services provided from the parent and used across every subsidiary in the group.

The certification requirement applied only to that operating business function. So the scope was drawn around that function and nothing else. The shared services sat outside the boundary and were captured in the interested parties register under clause 4.2, with their requirements of the business, and the business’s requirements of them, both recorded.

Nothing in clause 4.3 ties a scope to a legal entity, so scoping to one business function inside a larger group is entirely legitimate. What makes it audit-proof rather than merely defensible is how you handle the places where a shared service touches conformity. Clause 8.4 is triggered when a process, or part of a process, is provided by an external provider as a result of a decision by the organisation, and “external” means outside the organisation as your own scope defines it. A parent-company shared service sitting outside the boundary is therefore an external provider for the purposes of the standard. Recruitment and competence records feeding clause 7.2, systems holding documented information under 7.5, and order handling that touches clause 8.2 all need a defined control as well as an interested-party entry. Documented service arrangements with the group functions, plus monitoring of what they actually deliver, is usually the cleanest form for that to take.

The scope statement then said all of it in plain terms: which function was covered, which functions were supplied from the parent and therefore outside the boundary, and how work crossing the boundary was controlled. An auditor reading that has nothing left to ask.

A seed producer that sells through resellers

The business breeds, produces, treats, grades and packages agricultural seed. It does not sell to the farmers who plant it. Finished product moves to agricultural reseller businesses, and those resellers sell on to the end grower. The resellers also employ the agronomists who advise growers on what to plant, how to plant it, and how to manage the crop through the season.

The business did not want the downstream selling activity inside its management system, and there was no good reason for it to be there. So the boundary was drawn at the handover. Everything up to and including finished, graded, packaged product is in scope, and the internal sales team was treated as the customer, with its requirements defined under clause 8.2. That is properly supported. ISO 9000 defines a customer as a person or organisation that receives a product or service intended for them, notes explicitly that a customer can be internal or external, and lists the receiver of product from an internal process among its examples.

The question this always attracts is clause 9.1.2. If the customer is internal, what is customer satisfaction actually measuring? Here the answer is stronger than a perception survey. The real measure of whether the product met requirements is objective: finished product grade, germination rate and yield performance in the field. Beyond that, growers are closely guided and monitored by the resellers’ agronomists, and that performance information flows back through the channel. ISO 9001 lists dealer reports among its examples of methods for monitoring customer perception, so agronomist feedback arriving via the reseller is exactly the kind of input clause 9.1.2 contemplates, not a workaround for it. The resellers and the end growers stay in the interested parties register, and the route their feedback takes into the system is defined.

One thing that does not move with the boundary is statutory and regulatory obligation. Seed quality, treatment, labelling and biosecurity requirements attach to the product under clause 8.2.2 regardless of who is nominated as the customer, so they stayed inside the scope and inside the system.

What both cases have in common

In each case the scope was narrower than the organisation, and in neither case was a requirement of the standard determined to be not applicable. That distinction is worth carrying into your own audit. A boundary decision defines what the organisation is. A non-applicability decision says a requirement does not apply to what that organisation does. Auditors routinely conflate the two and ask you to justify an exclusion you never made. The cure is a scope statement that draws the boundary explicitly enough that the question never comes up.

How 4.3 differs across the standards

Clause 4.3 sits in the common Annex SL structure, so every modern standard has one, and the core requirement (you determine the boundaries and applicability, and you document it) is consistent. The considerations differ:

Standard	What its clause 4.3 also asks you to weigh
ISO 9001	Products and services; justification for any requirement not applicable
ISO 45001	The planned or performed work-related activities, and inclusion of activities, products and services within your control or influence that can impact OH&S performance
ISO 14001	Compliance obligations, organisational units, functions and physical boundaries, and your authority and ability to exercise control and influence
ISO 27001	The interfaces and dependencies between activities you perform and those performed by other organisations
ISO 42001	Your role or roles in the AI lifecycle (provider, producer, customer, partner) carried through from 4.1, and which AI systems sit inside the boundary; the scope then determines which requirements, controls and objectives apply

The core of clause 4.3 is common to every standard. What you must consider when drawing the boundary is not.

The ISO 27001 point deserves particular attention. Because information moves across organisational boundaries constantly, an ISMS scope that ignores interfaces and dependencies (cloud providers, outsourced development, managed services) is not credible, and it is the fastest way to a difficult Stage 1.

ISO 42001 gets to the same place from a different direction. Its 4.3 says less on its face, but the role determination it inherits from 4.1 does the heavy lifting: scope yourself as an AI user when you are in fact producing the model, or the reverse, and every control decision downstream sits on a misstatement. Get the role right and the AI management system scope follows from it.

If you run several standards, you do not need several scopes. One integrated management system with a single coherent scope, noting where a particular standard’s boundary differs, is far easier to maintain and to explain.

Clause 4.3: FAQs

Who determines the scope of the management system?

The organisation does. Clause 4.3 states that the organisation shall determine the boundaries and applicability of the management system to establish its scope. The certification body audits whether your determination is sound and properly justified, but the determination itself is yours to make.

Can we certify only part of our business?

Yes. Scoping to a site, division, product line or service stream is legitimate and common, provided the boundary is genuine, you can control what sits inside it, and the certificate does not mislead anyone about what was certified. It is also usually cheaper, because certification bodies price on the size and complexity of the audited scope.

What is the difference between the certificate scope and the management system scope?

The certificate scope is the short line the certification body prints on your certificate, written for an external reader such as a client or tender evaluator. The management system scope is the fuller documented information clause 4.3 requires: products and services, sites and boundaries, organisational units, processes covered, and any requirement determined not applicable with its justification. The one-liner is a summary of the other, and on its own it does not satisfy clause 4.3.

What does the scope statement have to contain?

It must be maintained as documented information, state the types of products and services covered, and provide justification for any requirement of the standard determined to be not applicable. In practice it should also make the physical and organisational boundaries clear.

Can we exclude a clause we do not want to do?

Only if the requirement is genuinely not applicable to your scope, and only if leaving it out does not affect your ability or responsibility to ensure conformity of your products and services and the enhancement of customer satisfaction. Difficulty, cost or unfamiliarity are not justifications.

Is “exclusion” still the right word?

Not in ISO 9001:2015. The 2008 version used “exclusions” and confined them to clause 7. The current standard uses “not applicable” and requires justification in the scope. A scope statement still written in the language of exclusions is a small but visible sign that the system has not been updated.

What makes a justification acceptable to an auditor?

Specificity. Say what is not applicable, why it does not apply to what you actually do, and which clauses control that work instead. A justification that states a fact about your operations closes the question. One that states an opinion invites the auditor to form their own.

How often should the scope be reviewed?

Whenever the business changes in a way that moves the boundary: new sites, new services, acquisitions, a new client requirement. It is also worth confirming the scope still reflects reality at management review, alongside the interested parties register.

How Streamline can help

Streamline designs, implements, audits and mentors practical ISO management systems for Australian businesses. Scope is one of the highest-leverage decisions in the whole project, because it sets your ongoing audit cost and how much of the business carries the administrative load. We help you draw the boundary deliberately, write a scope statement that leaves an auditor with nothing to argue about, and justify any non-applicability properly. See our ISO clause guides, our management system design services, or start with an independent gap analysis.

Speak with an experienced ISO auditor

For help with clause 4.3 or any part of your management system, contact us. Email hello@streamline.business or call Brisbane 07 3667 8280, Sydney 02 8315 7780 or Melbourne 03 9034 3990.

General guidance only. This article is general information, not legal, financial, safety or compliance advice, and it does not take account of your specific circumstances. Streamline ISO Consultants are ISO management-system consultants, not lawyers or licensed advisers. Standards, laws and regulator guidance change, and details were correct only at the time of writing. Always seek professional advice before acting. See our full Disclaimer.