Scoping Your ISMS: The Decision That Sets Your Audit Cost
What goes inside the fence, what stays out, and why "just prod" is rarely the simple answer
// @18xBan · GRC Series ·Chapter 02
One line on one page decides what an auditor will look at: the scope.
Monday, 8:52 AM
Dan Okafor leans into your doorway holding his phone like it's good news.
"Maya wants us certified. ISO 27001. I asked a certification body for a quote, and they sent back a form." He scrolls. "First box: scope of certification. Let's just put wayne-prod. Smaller scope, smaller bill, faster audit. Gotham Mutual only cares about production anyway."
Priya Nair, walking past with a coffee, adds: "Makes sense. Prod is where the customers are."
It sounds right. But you remember last week. The bucket you locked was called wayne-staging-data, and the file inside was prod-export-2024.sql.gz: a full production database export, sitting in staging, open to the internet.
Customer data doesn't stay where the architecture diagram says it lives.
"Give me until Friday," you tell Dan. "Before we write a scope, I want to know what we actually own."
Dan's plan: Put one AWS account on the form and call it done.
What a scope actually is
An ISMS (Information Security Management System) is the whole set of people, rules, processes and controls you use to run security. It's not a tool. It's the way the company works.
The scope is the boundary of that system. It says: these teams, these locations, these systems and this information are covered. Everything else isn't.
Think of it as a fence around a yard. Your controls are the house rules inside the fence. The auditor walks the fence line and checks that the rules are followed inside it. If you only fence the front lawn, the auditor never looks at the back gate. The dog still gets out the back gate. And your certificate still says "fenced."
ISO/IEC 27001:2022 Clause 4.3 is the requirement. In plain words, it asks you to:
Decide the boundaries and applicability of your ISMS;
Base that decision on the issues you found in Clause 4.1 (your context), the requirements you found in Clause 4.2 (what interested parties need), and the interfaces and dependencies between your work and work done by other organizations;
Keep the scope as documented information, meaning written down where people can find it.
It's one of the few documents the standard explicitly demands.
The unpopular truth: the scope line is the only part of your ISO certificate most customers will ever read. Gotham Mutual's vendor-risk team won't read your policies. They'll read the one sentence that says what the certificate covers, and check whether their data is inside it.
First, survey the land
You can't draw a fence around land you haven't surveyed. Wayne's documentation lists four AWS accounts: wayne-mgmt, wayne-prod, wayne-staging and wayne-dev. Documentation is what people remember. AWS Organizations is what exists.
From the management account, you run:
aws organizations list-accounts \
--query 'Accounts[].[Name,Id,State,JoinedMethod]' \
--output table
Sample output (illustrative). Wayne Industries is fictional.
----------------------------------------------------------
| ListAccounts |
+-----------------+---------------+---------+------------+
| wayne-mgmt | 104829365117 | ACTIVE | CREATED |
| wayne-prod | 238571940652 | ACTIVE | CREATED |
| wayne-staging | 349162058734 | ACTIVE | CREATED |
| wayne-dev | 457203816495 | ACTIVE | CREATED |
| hackathon-2023 | 562918374026 | ACTIVE | CREATED |
| marketing-test | 671034928157 | ACTIVE | CREATED |
| old-sandbox | 780145263398 | ACTIVE | CREATED |
+-----------------+---------------+---------+------------+
Seven accounts. Three that nobody wrote down.
A practical note: AWS retired the old Status field on Organizations account APIs on September 9, 2026. Use State, as above. If you have an older script filtering on Status, it may now quietly return nothing, which is the worst kind of inventory result: it looks clean.
To find out who owns each mystery account, check the root email address on each one:
aws organizations describe-account --account-id 562918374026 \
--query 'Account.[Name,Email,JoinedTimestamp]' --output text
Sample output (illustrative). Wayne Industries is fictional.
hackathon-2023 priya.nair@wayne-industries.example 2023-06-09T14:22:51.402000+00:00
You repeat that for the other two and walk the list around the office.
hackathon-2023: Priya's. "I thought that got shut down after the hackathon."old-sandbox: Dan's. "That's… from a while ago. I'll look."marketing-test: created for the outside web agency that built the marketing site. Nobody at Wayne logs into it.
Four accounts on paper. Seven in AWS.
The unpopular truth: most scope mistakes aren't choices. They're things nobody knew existed. A scope written from memory is a scope with holes.
The three inputs Clause 4.3 wants
Before you write a word of scope, collect the three inputs. Here's Wayne's short version.
1. Issues (Clause 4.1). What's going on inside and around Wayne that affects security?
Cloud-only SaaS company in Vancouver, British Columbia. No data centre of its own.
One security person.
Customer data has already ended up in the wrong account once.
2. Interested parties and their requirements (Clause 4.2). Who cares, and what do they need?
Gotham Mutual: a $1.8M deal, a vendor questionnaire, a request for assurance.
Existing customers: their personal information protected.
PIPEDA, Canada's federal private-sector privacy law: Wayne stays accountable for personal information it holds.
Maya and the board: a certificate that actually helps sell.
3. Interfaces and dependencies (Clause 4.3 c). Where does Wayne's work touch someone else's?
AWS runs the infrastructure; Wayne runs the configuration and the data.
The outside web agency works inside
marketing-test.Twelve vendors, none security-reviewed yet.
Three inputs go in, one scope statement comes out.
Why scope sets your audit cost (and why "just prod" doesn't save much)
Dan's instinct isn't wrong: scope does drive audit cost. But how it drives cost is the part most people miss.
Certification bodies calculate ISO 27001 audit time using ISO/IEC 27006-1:2024, Annex C. The starting point is the number of persons doing work under the organization's control within the scope, and the 2024 version makes clear this includes people who aren't employees, such as contractors. The certification body then adjusts that number up or down for complexity: how many systems, how much outsourcing, how much is already in place.
So think about what cutting wayne-staging from scope really does at Wayne. The same engineers deploy to prod and staging. The same people, the same laptops, the same GitLab, the same identity system. Removing the staging account removes almost none of the people. What it does add is a new boundary you now have to explain: how production data is kept out of an account you have declared out of scope.
Where scope genuinely saves money is when a whole part of the business, with its own people and systems, has nothing to do with the service you're certifying.
And the audit fee is only part of the bill. Every system inside the fence needs controls that operate and evidence that proves it. That's the bigger cost, and it's paid in your team's time.
Every certification body quotes differently. Ask yours how they count people and what adjusts the number.
The unpopular truth: a narrow scope mostly shrinks what you're forced to look at, not what you pay. The risk outside the fence doesn't get smaller because the auditor stopped looking.
Audit time starts with people in scope, then adjusts for complexity.
Field by field
| Field | What goes in it | Why it matters |
|---|---|---|
| Scope statement | One or two sentences naming the service or business covered | This is the line printed on the certificate |
| Organizational units | Teams and roles inside the boundary | Drives the headcount the auditor counts |
| Locations | Offices and sites, or "remote" | Tells the auditor where work happens |
| Services and processes | What the organization delivers and how | Links scope to the business, not just tech |
| Technology | Accounts, platforms, key systems | Where the controls will be tested |
| Information | What data is inside, especially personal data | What the fence is really protecting |
| Interfaces and dependencies | Outside parties and what they do | Clause 4.3 c, stated plainly |
| Exclusions and justification | What's left out, and why that's safe | The first thing an auditor pokes at |
| Inputs considered | Links to the 4.1 issues and 4.2 requirements | Shows the scope wasn't picked at random |
| Owner, approver, date, review | Who wrote it, who signed it, when it's next checked | Makes it evidence, not just a document |
Wayne before
Scope: Wayne production platform (
wayne-prodAWS account). Exclusions: — Approved by: — Date: —
Four problems in four lines. No people, no data, no interfaces, no reason for leaving the other six accounts out, and nobody signed it.
Wayne after
Scope statement: The information security management system of Wayne Industries covering the development, operation and support of the Wayne cloud SaaS platform, and the customer information processed by it.
Organizational units: Engineering, operations, security and customer support, plus leadership in its governance role. Contractors with access to in-scope systems are included.
Locations: Vancouver, BC office, and staff working remotely.
Services and processes: Software development, deployment, platform operations, customer support and access management for the SaaS platform.
Technology: All seven AWS accounts in the Wayne AWS Organization (
wayne-mgmt,wayne-prod,wayne-staging,wayne-dev,hackathon-2023,marketing-test,old-sandbox); Active Directory; self-hosted GitLab; company-managed laptops.Information: Customer personal information and account data, source code, credentials and secrets, backups and logs.
Interfaces and dependencies: AWS (infrastructure; Wayne manages configuration and data); outside web agency (works in
marketing-test); twelve vendors (to be reviewed).Exclusions: None at this stage.
Accounts pending closure:
hackathon-2023(owner: Priya Nair) andold-sandbox(owner: Dan Okafor) stay in scope until closure is complete.Owner: Head of Security. Approved by: Maya Lindqvist, CEO. Date: Friday. Next review: in 12 months, or sooner on a significant change.
Same form, two answers. Only one survives the first audit question.
Notice what happened to the three mystery accounts. The instinct is to leave them out because they're "not real." That's backwards. An account nobody watches is exactly where a leak starts. So they go in, with named owners, until they're closed. Once an AWS account is closed, it doesn't vanish on the spot; it sits in a closed state for a reinstatement window first. The scope says "until closure is complete" for that reason.
Also notice "Exclusions: None." A first honest scope is often wider than you'd like. That's fine. You can narrow it later, with a reason you can defend.
What an auditor accepts vs rejects
| Accepts | Rejects |
|---|---|
| A scope that names the service, people, locations, systems and information | A scope that's just an account name or a product name |
| Exclusions with a reason and proof nothing in scope depends on them | "Out of scope" with no reason given |
| An inventory that matches reality (e.g. the Organizations account list) | A scope written from memory that misses live systems |
| Interfaces listed with who does what | Outsourced work that's simply never mentioned |
| A dated approval from leadership | An unsigned document in a shared drive |
| A review date and a trigger for change | A scope nobody has looked at since it was written |
The auditor's favourite question: "And what's in that account?"
Interfaces: where your fence touches someone else's
The word "interface" scares people. It just means: a place where another organization does work that affects your security.
For Wayne, the clearest one is the web agency. They have access to marketing-test. Wayne can't control how the agency runs its own office, but Wayne can control what the agency is allowed to reach, and what's written in the agreement.
So the scope doesn't pretend the agency is inside Wayne. It says the agency is an interface, and that Wayne manages the relationship. You can't outsource accountability. PIPEDA says the same thing: an organization stays responsible for personal information it transfers to a third party for processing (Schedule 1, Principle 4.1.3).
AWS is the same story at bigger scale. AWS secures the infrastructure. Wayne secures what it builds on top: configurations, identities, data. The public bucket last week was Wayne's side of that line, not Amazon's.
"We just built the website." Then why do you have keys to an AWS account?
Friday, 3:15 PM: Evidence #2
You send Maya and Dan the scope document with a one-line summary: all seven accounts in, two being closed, nothing excluded yet.
Dan reads it twice. "Wider than I wanted."
"It's the one that's true," you say. "The narrow one would have lasted until the auditor asked about staging."
Maya replies at 3:15 PM: Approved.
That reply, with the document attached, gets filed next to last week's ownership email. Evidence #2: dated, named, approved.
Then you send Gotham Mutual the scope statement, the one-sentence version. It's not a certificate. But it's an honest answer to "what would your certificate cover?", and that's a better answer than a promise.
One document, one approval, one date.
What you actually do on Monday
Pull your real inventory. Cloud accounts, subscriptions, projects, tenants. From the platform, not from the wiki.
Put a name next to every account you didn't know about. If nobody claims it, that's your first risk.
Write your three inputs on one page: issues, interested parties and their requirements, interfaces.
Grab a published scope template and fill in every field, including "exclusions and justification."
Get it approved by someone with authority, in writing, with a date. Put a review date on it.
Framework mapping
Every framework asks the same first question: what exactly are we talking about?
Maturity ladder
| Stage | 20 people | 200 people | 2,000 people |
|---|---|---|---|
| Inventory | A spreadsheet from one cloud console | Scripted account export, checked quarterly | Automated discovery feeding a CMDB |
| Scope document | One page, founder approves | Template-based, CEO approves, annual review | Per-business-unit scopes, formal change control |
| Interfaces | A short vendor list | Vendor list with owners and contracts | Supplier register linked to risk and contracts |
| Exclusions | Usually none | A few, each justified | Many, each justified and tested |
| Change triggers | "When we remember" | New account or product triggers review | Account creation blocked until scope is updated |
Honestly, the 20-person version is a spreadsheet and an email. That's fine, as long as the spreadsheet is true.
Where Wayne sits: somewhere between the first two columns. The scope document now looks like the 200-person version. The inventory behind it is still one command run by hand.
Cheatsheet
Scoping your ISMS on one page.
The takeaway
The scope is a fence, and the auditor only walks the fence you draw. Draw it from what exists, not from what you remember. A narrow scope rarely saves much. It mostly hides what you'd rather not find. Get it signed, dated and reviewed, and it becomes evidence.
⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.
Illustrations in this post were created with AI assistance. Wayne Industries is fictional.