ISO 27001 Scope: How to Define Your ISMS Boundary
Scope is the first real decision you make in an ISO 27001 project, and it is the one that quietly sets your cost, your timeline and how much of your business gets dragged into the audit. Get it right and certification is a manageable piece of work. Get it wrong and you spend six months writing policies for parts of the business nobody asked about.
This guide covers what ISO 27001 actually requires of your scope, how to draw the boundary for a small Australian business, and the wording traps that cause trouble when a buyer reads your certificate.
What ISO 27001 requires
Scope sits in clause 4.3 of ISO/IEC 27001:2022, “determining the scope of the information security management system”. It asks you to establish the boundaries and applicability of your ISMS, and it does not let you pick them at random. You have to consider three things.
- The external and internal issues you identified under clause 4.1, which for most Australian businesses means things like regulatory obligations, the markets you sell into and how your business is structured.
- The requirements of interested parties from clause 4.2, meaning customers, regulators, insurers, investors and staff.
- The interfaces and dependencies between what your organisation does and what other organisations do for you.
That third point is the one people miss. Your cloud provider, your payroll platform and your outsourced helpdesk sit outside your ISMS boundary, but the connections to them do not disappear. They have to be identified, and they have to be managed through your supplier controls.
The standard also requires the scope to be available as documented information. In practice that means a short written scope statement, and it will end up printed on your certificate.
Drawing the boundary
The most useful way to think about scope is three zones rather than two: what is inside, what is outside, and what crosses the line.
Start with the information, not the org chart
Ask which information your customers, regulators and partners are trusting you with. Customer data in your platform, health or financial records, source code, personal information about staff. Then follow that information to the systems, cloud services, offices and teams that touch it. That trail is the natural shape of your scope.
Starting from the org chart instead tends to produce a scope that matches your reporting lines rather than your risk, and it usually pulls in whole departments that have no access to anything sensitive.
Smaller is usually smarter, within reason
A tighter scope means less documentation, fewer people to train, a shorter audit and a cheaper certificate. For a business of 20 to 100 people, a scope covering the product platform, the cloud environment that runs it and the teams that build and support it is often exactly right.
The limit is credibility. If a buyer reads your certificate and the scope excludes the thing they are actually buying, you have spent the money and not solved the problem. That is the test to apply: would the customer who asked for ISO 27001 be satisfied by this wording?
Multiple offices and remote teams
Locations belong in scope when work covered by the ISMS happens there. Most Australian small businesses now write something that covers their registered office plus remote and hybrid work, rather than listing every home address. If you have a Brisbane office and staff working from home across three states, say so in one sentence and cover the arrangements in your policies.
Four steps to a scope you can defend
The order below is deliberate. Most of the rework we see comes from writing the scope statement first and then discovering what it actually implies.
Step 1: map the information
List the information assets that matter and where each one lives. This overlaps heavily with the work you will do for your ISO 27001 risk assessment, so do it once and use it twice.
Step 2: follow it to the systems and people
For each asset, note the systems, cloud services, third parties and teams that create, store, process or transmit it. You are building the middle column of that diagram as you go.
Step 3: draw the line and record the exclusions
Decide what sits inside. Where something material sits outside, write down why. “The marketing website is excluded because it holds no customer data and is hosted separately” is a defensible sentence. Silence is not. Your auditor will ask about exclusions at stage 1, so having the reasoning ready saves a round trip.
Step 4: write the statement
Aim for two or three sentences that a customer could read without a glossary. A workable pattern: the provision of [what you do] to [who you do it for], including [the systems and locations involved], in accordance with the Statement of Applicability version [x] dated [date].
That reference to the Statement of Applicability matters, because scope and Statement of Applicability are the two documents an auditor lines up against each other first.
Common scoping mistakes
Scoping to a single product when you sell three
This is fine if the other two are genuinely separate, and a problem if they share a platform, a database or a support team. Buyers of the excluded products will eventually ask, and shared infrastructure makes the exclusion hard to defend.
Excluding the people who hold the keys
If your developers have production access, they are in scope regardless of which team they report to. The same goes for contractors. Access is what puts someone inside the boundary, not their employment arrangement.
Treating cloud services as out of sight
Excluding AWS or Microsoft from your scope does not mean ignoring them. It means you rely on their certifications, you manage the relationship as a supplier, and you remain responsible for how you have configured what they provide. Auditors look closely at this split.
Writing scope that will be wrong in six months
Naming specific product versions, individual servers or a particular office lease creates work every time something changes. Describe capabilities and locations at a level that survives normal growth.
Copying a competitor’s scope statement
It is tempting, and it produces wording that does not describe your business. Auditors read a lot of these and they notice when the scope mentions functions you do not have. Write your own, in your own words, and keep it short.
What happens to your scope after certification
ISO 27001 certification runs on a three year cycle, with surveillance audits in between and a recertification audit at the end. Your scope is checked at each of those points, and any material change to your business is a prompt to review it.
Acquiring a company, launching a product on new infrastructure or moving a function in house are all triggers. Changing scope mid cycle is normal and your certification body has a process for it. What causes problems is operating outside your certified scope for a year and mentioning it at the audit.
If you are still working out where you stand overall, an ISO 27001 gap analysis will tell you what your realistic scope and timeline look like before you commit budget.
Common questions
Can we certify just one part of the business?
Yes. Partial scopes are common and entirely legitimate, as long as the boundary is clear, the exclusions are justified and the interfaces to the rest of the business are controlled. Your certificate will state the scope, so the market sees exactly what you certified.
Does a smaller scope make certification cheaper?
Usually, yes. Audit effort is driven largely by the number of people in scope and the complexity of what is covered, so a tighter boundary means fewer audit days and less documentation to maintain. It is the single biggest lever on the cost of ISO 27001 certification in Australia.
Can we change our scope after we are certified?
Yes. Talk to your certification body first, because expanding the scope may require additional audit activity before the certificate is reissued. Reducing scope is usually simpler. Either way, do it deliberately rather than letting reality drift away from the wording.
What if a customer says our scope is too narrow?
Take it seriously, because it means the certificate is not doing the job you bought it for. Sometimes the fix is a scope extension at the next surveillance audit. Sometimes the honest answer is that the customer wants evidence about a system that genuinely sits outside, and a penetration test or an additional control gives them what they need faster.
Getting the boundary right the first time
Scope is a business decision dressed up as a compliance question. The right answer balances what your buyers need to see against how much of your organisation you are prepared to run under a management system.
Siege Cyber helps Australian businesses define workable scopes and get through certification without gold plating. Have a look at our ISO 27001 services, or contact us for a straight conversation about what your scope should cover.