TL;DR
Clause 4.3 is the only part of Clause 4 that makes you produce a document. Your scope statement goes on your certificate, and buyers read it. It is the shortest paragraph in your ISMS and the one with the most consequences.
- Set the boundaries and the applicability of the ISMS. Then keep the scope as documented information. Clauses 4.1 and 4.2 require no document. This one does.
- Three inputs feed it. The issues from 4.1, the requirements from 4.2, and the interfaces and dependencies between your activities and other people’s.
- The third input is the one teams skip. It is where your boundary meets your cloud provider, your MSP and your parent company. It is also where a scope statement survives audit, or falls over.
- A scope narrow enough to be cheap can be worthless. If your certificate does not name the product your buyer is buying, it tells them nothing.
- Scoping something out is not the same as excluding an Annex A control. Two mechanisms, two justifications, and auditors notice when you confuse them.
- Scope sets your audit bill. ISO/IEC 27006-1:2024 changed how certification bodies calculate audit time. Every accredited body has had to use it for all clients since 31 March 2026.
Sources: ISO/IEC 27001:2022 · ISO/IEC 27006-1:2024 · ANAB transition notice
What Clause 4.3 asks for #
ISO/IEC 27001 is a copyrighted standard, so this guide paraphrases rather than reproduces it. Buy the text before you build against it.
Clause 4.3 closes the Context of the organization section. It tells you to determine the boundaries and the applicability of your information security management system, and to write down what you decided. Three inputs feed the decision.
- The issues from Clause 4.1. The external and internal conditions that bear on your ISMS.
- The requirements from Clause 4.2. What your customers, regulators and other parties need from you.
- Interfaces and dependencies. Where your activities meet activities other organizations perform. This is the input nobody finishes.
Then the sentence that separates 4.3 from its neighbours. The scope has to exist as documented information. Clause 4.1 and Clause 4.2 carry no such requirement. This one does, and it is the only place in Clause 4 where a document is not optional.
What a scope statement contains
Four things, in a paragraph or two. What the ISMS covers, meaning the products or services. Which legal entity or entities. Which locations and which cloud regions. And the interfaces, meaning what you depend on and who runs it. If a reader cannot answer “is the thing I am buying inside this” then the statement is not finished.
Interfaces and dependencies: the part teams skip #
Most scope statements name a product and a city and stop. The clause asks for more than that.
Your ISMS has edges. At every edge, someone else does part of the work. Your cloud provider runs the hardware. Your MSP patches the laptops. Your payroll vendor holds employee records. Your parent company runs identity, or the network, or the security team. Each of those is an interface, and the clause wants you to have thought about it.
Name them, and say who does what. Two sentences per interface is enough. This is also the work that feeds your supplier controls in Annex A, so it pays for itself twice.
What trips people up
A dependency you did not name does not leave your scope. It sits inside it, undocumented, until an auditor asks who runs your identity provider and nobody in the room agrees on the answer. Naming an interface does not push the risk onto the other party. It records where your control ends and theirs begins.
The narrow scope trap #
You can scope an ISMS down to one product, one team and one office. The audit gets cheap and the certificate arrives fast. Consultants suggest this often, and sometimes it is right.
Here is the part that gets left out. That scope statement goes on the certificate, and your buyer’s security reviewer reads it.
A certificate scoped to “the ISMS supporting the hosting of Product A at the Toronto office” is valid. Now suppose the buyer wants Product B. It runs on AWS, and a team outside that boundary builds it. The certificate proves nothing about what they are buying. Worse, a careful reviewer sees a scope that excludes the thing on the invoice, and wonders what else you left out.
The test is simple. Take your biggest open deal. Read your draft scope statement as their security reviewer. Can they see the product they are buying, the systems it runs on, and the team that builds it? If not, you are about to buy a certificate that will not close the deal you bought it for.
Narrow is fine when it matches what you sell. Narrow to save money on the audit, and you paid for a document nobody can use.
Scoping out is not excluding a control #
People confuse these two all the time. They are different mechanisms.
| Scoping out (Clause 4.3) | Excluding a control (Statement of Applicability) | |
|---|---|---|
| What it does | Puts an activity, system, site or entity outside the ISMS boundary | Keeps the boundary as it is, and says a named Annex A control does not apply inside it |
| Where you record it | The scope statement, and the certificate | The Statement of Applicability |
| What you must justify | Why the boundary sits there, using 4.1, 4.2 and your interfaces | Why that control is not applicable to what is inside |
| What a buyer sees | Everything. The scope is on the certificate | Nothing, unless they ask for the SoA |
The common error runs one way. A team scopes a system out of 4.3, then writes Annex A justifications as if the control were not applicable to the whole company. An auditor reading both documents finds the mismatch.
What Canadian buyers read on your certificate #
Three things matter more here than most guidance admits.
Which legal entity #
Many Canadian companies are subsidiaries of US parents, or the reverse. A parent company’s certificate does not cover a subsidiary by default. If your buyer needs the Canadian entity certified, that entity has to appear in the scope statement by name.
This runs both ways. A vendor sends you a certificate with the parent’s name on it. Check whether the entity on your contract sits inside the scope. It often does not.
Which locations, and which cloud regions #
Canadian buyers ask where their data sits. Data residency reaches your ISMS as a customer requirement under Clause 4.2. Clause 4.3 is where it becomes visible. A scope naming your Canadian region tells a buyer something. A scope naming no location tells them nothing, and they will ask anyway.
This is one place ISO 27001 does more than SOC 2, which has no data residency criterion and no equivalent public scope statement.
Which body issued it #
The Standards Council of Canada accredits certification bodies in Canada and signs the IAF Multilateral Recognition Arrangement, which is what makes a Canadian certificate travel. A certificate from an unaccredited body carries the same words and much less weight. Buyers who know the difference check.
Your scope sets your audit bill #
Scope is not only a positioning decision. It is a priced one.
Certification bodies work to ISO/IEC 27006-1, which sets their rules for audit and certification. The 2024 edition superseded ISO/IEC 27006:2015 and its 2020 amendment. It changed how audit time gets calculated, introducing the effective number of personnel and new handling for scope extensions and multi-site situations.
ANAB required its accredited bodies to use the 2024 edition for all clients no later than 31 March 2026. That date has passed, so the calculation behind your quote is the new one.
The practical effect: how many people sit inside your boundary drives your audit days, and adding sites or extending scope later has its own rules. Ask your certification body to show the calculation before you fix the boundary. Two scope options that look similar on paper can differ by several audit days.
Where the output has to land #
| Destination | What it does with your scope |
|---|---|
| The certificate | Your certification body prints the scope statement on it, in public, for the life of the certificate. Highest stakes, and the destination teams think about last. |
| Statement of Applicability | Controls apply to what sits inside the boundary. Move the boundary and the SoA changes with it. |
| 6.1 Risk | You assess risk to what is in scope. A risk assessment covering more than your scope wastes effort. One covering less is a gap. |
| 9.3 Management review | You revisit scope as the organization changes. New product, new region, new entity, new acquisition. |
How to tell if yours is any good #
- Can a buyer find their product in it? Read it as your biggest prospect’s security reviewer. If they cannot see what they are buying, rewrite the boundary or accept that the certificate will not help that deal.
- Does every boundary have a reason? Point at an issue from 4.1 or a requirement from 4.2 for each edge. “This is what we could afford to audit” is not a reason you can put in front of an auditor.
- Are the interfaces named? Cloud, MSP, payroll, parent company, subprocessors. An empty list means you never answered the third input.
- Does it match the Statement of Applicability? Anything you scoped out should not reappear as a control exclusion, and the reverse.
- Would you show it to a customer? You will not get the choice. It goes on the certificate.
Frequently asked questions #
Does ISO 27001 require a documented ISMS scope?
Yes. Clause 4.3 requires the scope to exist as documented information. It is the only documented information requirement in Clause 4. Clause 4.1 and Clause 4.2 carry none, which surprises most teams and catches out most template vendors.
What should an ISO 27001 scope statement include?
Four things. The products or services the ISMS covers. The legal entity or entities. The locations and cloud regions. And the interfaces, meaning what you depend on and who operates it. A reader should be able to tell whether the thing they are buying sits inside the boundary.
Can we exclude parts of the business from the ISMS scope?
Yes. ISO 27001 does not require you to certify the whole company. It requires you to set a boundary and justify it against your issues, your interested party requirements and your interfaces. The commercial question is separate. A boundary that excludes what you sell produces a valid certificate that will not satisfy a buyer.
What is the difference between scoping out and excluding an Annex A control?
Scoping out puts an activity, system or entity outside the ISMS boundary, and it shows on your certificate. Excluding a control keeps the boundary where it is and records in the Statement of Applicability that a named Annex A control does not apply inside it. Different mechanisms, different justifications. Auditors notice when the two documents disagree.
Is our cloud provider inside our ISMS scope?
Your use of it is. Their operation of it is not. That relationship is an interface under the third input of Clause 4.3. Name the provider, say what they run and what you run, and carry that into your supplier controls. You cannot certify someone else’s infrastructure, and you cannot pretend it is not there.
Does a US parent company’s ISO 27001 certificate cover our Canadian entity?
Only if the Canadian entity appears in the scope statement. A parent’s certificate does not extend to a subsidiary by default. If a buyer contracts with your Canadian entity, the scope statement has to name it. The same check works in reverse when a vendor sends you one.
Key takeaways #
- Clause 4.3 is the only part of Clause 4 that requires a document.
- Three inputs: the 4.1 issues, the 4.2 requirements, and your interfaces and dependencies.
- Interfaces are the input teams skip, and the one that decides whether the boundary survives audit.
- Your scope statement goes on the certificate. Buyers read it.
- A scope that excludes what you sell is valid, and useless in a sales conversation.
- Scoping out and excluding an Annex A control are different mechanisms. Keep them consistent.
- Name the legal entity and the locations. Canadian buyers check both.
- Scope drives audit days under ISO/IEC 27006-1:2024, mandatory for all clients since 31 March 2026.
Set the boundary once, and set it right #
Nank.ai runs ISO 27001 programmes for Canadian companies from Toronto, with a dedicated compliance manager and your data held in Canada. We draft the scope against your open deals, not against your audit budget, and we get the certification body to show the audit time calculation before you commit.
