What an ISO 27001 scope statement actually looks like
An ISO 27001 scope is a written statement of which parts of your organisation, locations, systems and services the ISMS covers, including named exclusions and the justification for each boundary decision.
What a scope statement actually contains
Clause 4.3 of ISO 27001 requires you to document the boundaries and applicability of your ISMS. In practice that means a short written statement, usually one to two paragraphs, that names the organisational units, physical locations, information systems and services in scope, states any exclusions, and explains why those boundaries make sense given your interfaces and dependencies on things outside the boundary.
A worked example for a SaaS company:
"The ISMS covers the design, development, hosting and support of the [Product Name] platform, delivered from AWS eu-west-1 and us-east-1, including all engineering, DevOps, customer support and sales operations functions that access customer data or production systems. It covers the company's single office location in London. It excludes the marketing website hosted on a separate static hosting account with no customer data, and excludes the finance and HR functions which do not process customer data and are covered by separate contractual controls with third-party providers."
Notice what that statement does. It names infrastructure (AWS regions, not just "the cloud"), names functions (engineering, DevOps, support, sales ops), names a physical location, and explicitly excludes two things with a reason attached to each. An auditor reading this can immediately tell what they're going to sample against, and so can your sales team when a prospect asks what the certificate actually covers.
Why vague scopes get rejected or embarrassed later
I've reviewed scope statements that say something like "the ISMS covers all information assets of the organisation." That's not a scope, it's an aspiration. It gives the certification body nothing to audit against and gives your customers no way to know whether their data is actually inside the boundary. The most common failure mode is scoping the whole company when only the product engineering org actually touches customer data. That inflates your Statement of Applicability, drags HR and finance policies into audit evidence requests, and makes the surveillance audits larger than they need to be for no security benefit.
The opposite failure, scoping too narrowly to dodge awkward controls, gets caught differently. If your scope says "the production AWS environment" but excludes the CI/CD pipeline that deploys to it, or excludes the support team that has read access to customer data via a ticketing tool, a competent auditor will ask why those are outside the boundary given they clearly interface with it. Exclusions need a defensible reason, not just convenience.
Boundary decisions that come up in almost every scoping exercise
A few decisions recur across most companies I've scoped. Shared infrastructure: if your production and staging environments share an AWS account and IAM roles, you generally can't exclude staging credibly, because a compromise there affects production. Third-party processors: you don't bring your cloud provider's infrastructure into your own ISMS scope, but you do need to show supplier due diligence over it, which sits inside your scope as a control rather than as a scoped asset. Remote and contractor access: if contractors have production access, the devices and access paths they use need to be inside scope even if the contracting company itself isn't your employee base. Multi-product companies: if you sell three products but only one handles customer data that triggers compliance requirements, you can scope just that product line, provided the shared platform underneath it is also included.
| Scope decision | Usually in scope | Usually excludable |
|---|---|---|
| Production AWS account | Yes, always | Rarely, if ever |
| CI/CD pipeline deploying to production | Yes | No, if it has write access to production |
| Staging environment sharing IAM with prod | Yes | Only if fully isolated account |
| Marketing website, no customer data | No | Yes, commonly excluded |
| HR and payroll systems | Depends on data handled | Yes, if no customer data flows through them |
| Support ticketing tool with customer PII | Yes | No |
How scope interacts with your Statement of Applicability
Your scope and your Statement of Applicability (SoA) have to agree with each other. If your scope names AWS infrastructure, engineering, and support, your SoA needs to address controls relevant to cloud configuration, access management, and incident handling for those functions specifically, not generic policy language copied from a template. Auditors cross-reference the two documents constantly during stage one review, and a mismatch, where the scope mentions something the SoA never addresses, is one of the fastest ways to pick up a non-conformity before the audit has properly started.
Writing your own: a practical sequence
Start by listing every system that stores, processes or transmits customer data, including anything a support agent or engineer can query manually. Then list every team with standing access to those systems. Then list physical locations where staff work from regularly. From those three lists, draft the inclusion statement first, then go back and identify anything adjacent that you want to exclude, and write down the specific reason for each exclusion before you finalise it. If you can't articulate the reason in one sentence, it probably shouldn't be excluded.
Keep the final statement to a paragraph or two. Certification bodies and customers both read scope statements quickly, and a scope that needs a page of explanation usually signals the underlying architecture hasn't been simplified enough to certify cleanly.
Related: a ISO 27001 consultant can review a draft scope before you submit it, and a fractional cloud compliance architect is useful when the boundary questions are really AWS account and network design questions in disguise. For ongoing scope changes as infrastructure grows, a fractional CISO keeps the scope statement current between audits.
Common questions
Can I change my ISO 27001 scope after certification?
Yes, but any material change, such as adding a new product, region or data type, needs to go through your change management process and usually gets reviewed at your next surveillance audit. Significant changes, like acquiring a company or moving to a new cloud provider, can trigger an earlier review from your certification body.
Does the whole company need to be in scope?
No. Many certified companies scope only the product or business unit that handles the data customers actually care about, such as a SaaS platform, while excluding unrelated internal functions. The exclusion needs a documented reason, and anything that interfaces with the in-scope system usually has to be included too.
What happens if my scope is too broad?
You end up pulling functions like HR, finance or unrelated product lines into your audit evidence requirements, which increases the size and cost of every surveillance audit without improving security outcomes. It's worth narrowing scope deliberately rather than defaulting to 'the whole company' for simplicity.
Do customers actually read the scope statement?
Security-conscious buyers do, particularly enterprise procurement and security teams during vendor review. A vague scope statement is a common reason a certificate gets questioned in a sales cycle, because the buyer can't tell whether the product they're buying is actually covered.
Should cloud infrastructure be named specifically in the scope?
Yes. Naming the cloud provider, regions and account structure, rather than saying 'the cloud environment', gives both auditors and customers a concrete picture of the boundary and avoids ambiguity about shared tenancy or third-party processing arrangements.
How this article was made: drafted with AI assistance from my own engagement notes and lab work, then fact-checked and edited by me (Sahil Dubey) before publishing. Corrections: hi@sahildubey.us.