ISO 27001 scope statement: how to write one
The scope statement is one paragraph, it gets printed on your certificate, and it decides more about the cost and the difficulty of the project than any other decision you will make. Most first drafts are either too vague to certify or too narrow to be useful to the customer who asked.
An ISO 27001 scope statement is a single paragraph required by clause 4.3 that names what the management system covers: the products or services, the organizational units and the locations, and the boundary where your responsibility ends and someone else's begins. It goes on the certificate verbatim, which means the customer who asked you for ISO 27001 will read it and decide whether it covers the thing they buy from you. Get it wrong in the tight direction and you pay for an audit that does not answer their question. Get it wrong in the loose direction and you have signed up to secure departments that had no reason to be in the project.
1 paragraph Length of the document clause 4.3 requires
$15,000 to $40,000 Certification body fee this paragraph sets, CAD
What clause 4.3 actually requires
The clause is short. You determine the boundaries and applicability of the management system to establish its scope, and in doing so you consider three things: the external and internal issues from clause 4.1, the requirements of interested parties from clause 4.2, and the interfaces and dependencies between what you do and what other organizations do for you. The scope is then held as documented information.
The third consideration is the one that makes scoping hard and the one most draft statements ignore. You cannot draw a boundary around your own product and leave the cloud provider, the payroll processor and the offshore development partner outside without saying anything about them. They are inside the interfaces and dependencies question, and an auditor will ask how the boundary is managed rather than whether it exists.
- In scope
- Activities you perform, in units you control, at locations you name. These get audited directly and evidence is sampled from them.
- Interface
- The point where an in-scope activity depends on something outside. The interface is always in scope even when the other party is not, and it is managed through the supplier and cloud controls in Annex A.
- Out of scope
- Genuinely separate activities, business units or locations. Legitimate, and it has to be stated rather than implied, because a reader of the certificate should not have to guess.
- Exclusion
- A different concept entirely, and one that applies to Annex A controls rather than to scope. Do not use the word in a scope statement.
How much does the scope change the price
Accredited certification bodies derive audit duration from the audit time tables in the ISO/IEC 27006 series, starting from the effective number of people in scope and adjusting for complexity. The complexity adjustment is where scope wording turns into money: number of sites, number of distinct technology environments, how much is outsourced, how much personal information is handled, and whether the people in scope all do broadly similar work.
| Scope decision | Effect on audit days | Effect on first-cycle fee |
|---|---|---|
| One product line rather than the whole company | Fewer effective personnel, one technology environment | Can halve it |
| Adding a second physical office | Multi-site sampling, possible travel | Add $2,000 to $8,000 |
| Naming a subsidiary in another country | Second legal entity, sometimes a second auditor | Add $5,000 to $15,000 |
| Personal information brought explicitly in scope | Complexity uplift and a longer stage 2 | Add $1,500 to $5,000 |
| Corporate functions such as finance and HR included | More people, more distinct activities | Add $3,000 to $10,000 |
| Contractors counted as effective personnel | Headcount band moves up | Depends on the band boundary |
| Typical first-cycle certification body fee, Canadian company under 250 staff | Stage 1 plus stage 2 | $15,000 to $40,000 CAD |
The line-by-line version of that invoice, including how a body converts days into a number, is on the itemised cost page, and the three-year total is on the cost breakdown for Canada.
Two scope statements you can adapt
Both of these are complete. Both would be accepted. They are written for the two situations that produce most Canadian certificates.
Example one: a single-product software company
The information security management system covers the design, development, hosting, support and operation of the Acme Payments platform, delivered as a software service from Amazon Web Services regions in Canada, including the engineering, product, customer support, security and infrastructure functions of Acme Software Inc., operating from its office at 000 Example Street, Toronto, Ontario and from remote work locations in Canada. Corporate finance, human resources and marketing are included insofar as they process information belonging to platform customers. The Statement of Applicability version 1.4 dated 12 June 2026 applies.
Example two: a services firm with two offices
The information security management system covers the provision of managed IT and security operations services to clients, including service desk, monitoring, patch management and incident response, delivered by Example Managed Services Ltd. from its offices in Calgary, Alberta and Halifax, Nova Scotia and from client sites in Canada. The scope covers all employees and contractors performing those services. Hardware resale and procurement activities are outside the scope. The Statement of Applicability version 3.0 dated 4 March 2026 applies.
Notice what both do. They name the service rather than the department. They name locations. They say what is outside where a reader might reasonably assume otherwise. They reference the Statement of Applicability by version and date, which is conventional rather than required and makes the certificate easier to interpret. Neither of them reaches for phrases like industry leading or ongoing commitment, because a scope statement is a boundary definition rather than a marketing sentence.
What a bad scope statement looks like
| Draft | Why it fails | Fix |
|---|---|---|
| "All information security activities of the company." | Names no service, no location and no boundary. A certification body will send it back before it quotes | Name the service, the functions and the sites |
| "The security team and its systems." | Scopes a department rather than an activity. The customer buys the product, not the team | Scope the product or service the customer buys |
| "The production environment." | Excludes the people who build and deploy into it, which is where most real risk sits | Include development, deployment and support |
| "All operations excluding the Winnipeg office." | Legitimate only if Winnipeg genuinely does something else. If Winnipeg runs support for the in-scope product, the exclusion is not defensible | Either bring it in or say what it does instead |
| "Head office operations, subject to available resources." | Conditional language in a scope statement is a nonconformity waiting to happen | Remove the condition. Scope is a boundary, not an intention |
| "ISO 27001 certified" with no scope printed at all | Not a scope statement, and a certificate that carries no scope is not from an accredited body | Check the certificate itself, then read how to verify a body |
What happens when the scope is too narrow
This is the more expensive failure, and it does not show up until the certificate is issued. A company scopes only its hosting infrastructure to keep the audit small, gets certified, sends the certificate to the enterprise customer who asked, and the customer's vendor risk analyst reads the scope line, sees that software development is not in it, and asks how a certificate that excludes the development of the software they are buying gives them assurance about the software they are buying. The answer is that it does not, and the next audit is twelve months away.
Two tests before you finalise. First, print the scope paragraph on its own and send it to the person who asked you for ISO 27001, before you sign with a certification body. If they cannot tell from that paragraph that the thing they buy is covered, rewrite it. Second, ask whether a competitor could write the same sentence about a much smaller amount of work. If they could, so can a sceptical reader.
You cannot exclude something because it is difficult
A scope boundary has to follow from what the organization does, not from where the evidence is weak. Leaving the offshore development team out because their access controls are untidy is the exclusion an auditor is most likely to probe, because clause 4.3 c) requires you to consider interfaces and dependencies and that team is a dependency of the in-scope service. Bringing them in and treating the gap as a risk is the honest route and it survives the audit. Scoping around it usually does not survive the customer.
When a narrow scope is the right answer
The counter-case, because the argument above is not one-directional. A narrow scope is correct in three situations that come up often. A holding company with genuinely unrelated businesses should certify the one that sells to enterprises and leave the others out, because there is no reason for a construction subsidiary to inherit a software company's ISMS. A company mid-acquisition should scope to the existing entity and add the acquired one at recertification, since bringing an unintegrated business in during year one produces nonconformities that belong to someone else's controls. And a company whose first certificate is a deadline commitment to one customer should scope tightly, certify, and widen at the year-three recertification, which is cheaper than delaying the first certificate by six months.
What makes those defensible is that in each case the narrow scope still covers the service the customer buys. The failure mode is not narrowness. It is narrowness that cuts through the middle of the thing being sold.
Writing it in an afternoon
- Write down the service the asking customer buys, in their words.
- List every function that touches it: engineering, support, infrastructure, and the corporate functions that hold customer data.
- List locations, including remote work as a category rather than as addresses.
- List the outside parties the service depends on. Each one is an interface and belongs in the supplier register, not in the scope sentence.
- Name anything a reader would assume is included that is not, and say what it does instead.
- Draft one paragraph. Read it as the customer. Then read it as an auditor looking for a gap between the sentence and the organization chart.
- Approve it, version it, and put it under the document control rules in clause 7.5.
Once the boundary is fixed, the rest of the project follows from it: the asset inventory is bounded by it, the risk assessment only considers risks inside it, and the Annex A selection is judged against it. That is why the implementation sequence puts scope second, immediately after confirming what the customer asked for.
Get a second opinion on your scope
Send us the draft paragraph and your headcount and we will match you with Canadian firms who will tell you what it costs to certify as written.
Get matchedCommon questions
What is an ISO 27001 scope statement?
It is the paragraph required by clause 4.3 that defines the boundaries and applicability of your information security management system: the services covered, the organizational functions, the locations, and anything deliberately outside. It is held as documented information and it is printed on the certificate, so it is the part of your management system your customers actually read.
Can we certify just one product?
Yes, and it is the most common shape for a first certificate. The scope has to cover everything that product depends on inside your organization, including the people who develop, deploy and support it. Scoping the hosting environment while leaving development out is the version that gets questioned by customers rather than by auditors.
Do we have to include our head office if everyone is remote?
You have to state where the work happens. A fully remote Canadian company normally scopes to a registered address plus remote work locations in Canada, and the physical controls in Annex A are then applied to laptops, home working and storage media rather than to a building. That is a supportable position and it is described in the physical controls section of the Annex A page.
Can we change the scope after we are certified?
Yes. A scope extension is normally handled at a surveillance audit or at recertification, with additional audit days priced for the new part. A reduction is simpler and usually just a certificate reissue. Either way the change itself is an ISMS change and clause 6.3 expects it to be planned and recorded rather than announced to the auditor on the day.
Does the scope statement go on the certificate?
Yes, close to verbatim, which is why bodies push back on vague wording. ISO/IEC 17021-1 requires the certification document to identify the scope of certification, so a certificate with no scope printed on it, or one with only a marketing phrase, should make you check the accreditation before you accept it from a supplier.
How does scope affect the number of audit days?
Directly. The audit time tables start from the effective number of people inside the scope, then adjust for the number of sites, the number of distinct technology environments, the proportion outsourced and the amount of personal information handled. Every one of those is a scope decision, which is why the paragraph is worth an afternoon rather than ten minutes.