The first decision in building an ISMS is scope — and it is also the decision that costs the most to reverse. Scope determines what goes into the asset register, what the risk assessment covers, which departments the procedures bind, where internal audit walks, and how many auditor-days the certification body charges. Scope very nearly determines the total effort of the project.
Despite that, it is usually settled on instinct: "let's do the whole company," or "let's start with engineering." The material for a better decision is rarely laid out. In practice only two questions matter: how much effort you can absorb, and whether the scope statement printed on the certificate will satisfy the customers who asked for it. Balancing those two is what scope design is.
This article sets out how to decide. For the standard as a whole see What Is an ISMS (ISO/IEC 27001)?, and for what this decision drives downstream, Clause 6: Planning.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual decisions on those.
Why This Is Where People Get Stuck
Three causes account for nearly all of it.
1. "Scope" carries two meanings
In the standard, scope means the organisational, physical and logical boundary within which the management system operates. Internally, people hear "scope" and picture "the information we need to protect." The two overlap but are not the same. A department outside the ISMS routinely touches information inside it, and how that is handled is the crux of the design.
2. People do not realise there are several axes
Scope is not one-dimensional. Boundaries must be drawn on four axes: organisation (which legal entities, which departments), physical (which sites), logical (which systems and networks), and business (which services and processes). Decide on one axis alone and the gaps surface later — "head office is in scope, but what about people working from home?"; "engineering is in scope, but IT holds the admin credentials for the SaaS they use."
3. Nobody checked what the customer actually looks at
Most companies certify because a customer asked. But the certificate carries a printed scope statement, published in the accreditation body's register. If a narrow scope does not match the business the customer cares about, the exercise misses its purpose. "They have the certificate, but that service turned out to be excluded" is a real objection in sales conversations.
Deciding scope from an effort estimate alone always drops the third point. Settle "to whom, to show what" first; then discuss effort.
What You Are Actually Deciding
| Axis | What to decide | Typical wording | What breaks if you skip it |
|---|---|---|---|
| Organisation | Which entities, departments and employment types are included | "Healthcare Division, ◯◯ Inc. (including contract and dispatched staff)" | On-site contractors fall outside the rules |
| Physical | Which sites and areas; how remote work is treated | "Tokyo head office (5F, ◯◯ Building) and remote-work environments" | Remote work sits outside scope while everyone works from home |
| Logical | Which systems, networks and cloud services | "Production environment of ◯◯ and the corporate network operating it" | The identity platform run by IT is left hanging |
| Business | Which services and processes | "Planning, development, operation, maintenance and support of ◯◯, a SaaS for healthcare providers" | The certificate's wording does not match the service the customer named |
The four combined, in one sentence, become the scope statement on the certificate. Working backwards from that sentence is the practical move: write it first, then ask whether a procurement officer reading it would see what they asked for, and only then fill in the interior.
You must also settle how interfaces with what lies outside are handled. The standard requires you to consider the interfaces and dependencies between activities inside the scope and those performed by others. In other words: narrowing is legitimate, but the boundary that narrowing creates must be explainable.
| Kind of interface | Example | How to handle it |
|---|---|---|
| Out-of-scope internal department | Finance handles billing data | Treat as "external" from inside the scope; state in a procedure what is provided and on what terms |
| Group company | Parent's IT procures and manages laptops | Document an arrangement equivalent to supplier management: demarcation and requirements |
| Cloud services | IaaS, SaaS, identity providers | Manage as suppliers; state your own side of the shared responsibility model |
| Outsourced work | Part of development, an outsourced call centre | Manage via contract clauses and check sheets; state whether sub-contracting is permitted |
How to Do It
Step 1 — Fix the purpose: to whom, to show what
Turn the motivation into a specific counterparty and situation: a hospital's procurement requirement, a pharmaceutical company's vendor review, a public tender. Each implies a different breadth. If you have been sent an actual check sheet, reading it is the shortest path. See When ISMS Becomes a Condition of Trade.
Step 2 — Anchor on the business axis
Decide which service is covered first. For a healthcare company, the flagship service handling sensitive data is the natural anchor, and it becomes the core of the certificate wording.
Step 3 — List everything that makes that service work
Enumerate the departments, sites, systems and people required to deliver it. This is where "we are actually involved" surfaces. A service believed to live entirely in engineering turns out to involve sales receiving customer data, support querying production, and IT issuing accounts.
Step 4 — Draw the line, and describe what you excluded as an interface
Excluding is legitimate. What is required is describing what crosses the line you drew.
Step 5 — Write the wording and circulate it
Draft the sentence you expect on the certificate and show it to sales and the executive team. Skipping this is what forces a scope-extension audit later.
Step 6 — Document and approve
Scope must be maintained as documented information — a standalone document or a section of the ISMS manual.
Breadth trades off roughly as follows.
| Scope choice | Build effort | Auditor-days | Persuasiveness of the certificate | Fits when |
|---|---|---|---|---|
| One service, engineering only | Low | Few | Limited; adequate for that service alone | Single flagship service; speed matters most |
| Flagship service + all involved departments | Medium | Medium | Strong; demonstrates the business as operated | The usual answer for B2B healthcare |
| Whole company, multiple businesses | High | Many | Strongest; absorbs future additions | Several businesses all needing evidence |
| A single site | Low–medium | Few–medium | A printed site name can mislead | Only where work genuinely completes at that site |
For B2B healthcare, "flagship service plus all involved departments" is usually where this lands. Restricting to engineering leaves out support's access to production data and the hospital information sales receives — precisely what customers care about. See also ISMS for Small Organisations.
Where It Goes Wrong
Scoped to engineering, but the customer wanted the whole service
The most expensive failure. Extending scope generally requires an additional audit, with its own cost and lead time. It follows from skipping steps 1 and 5.
Remote work is not in scope
The statement stops at "5F, ◯◯ Building" while most staff reach production from home. Name remote work explicitly and design controls for it — device management, network, preventing overlooking by household members.
Writing cloud off as "out of scope"
IaaS and SaaS are not your equipment, so the temptation is to exclude them. But if your service runs on that cloud, the data and applications on it are in scope. The correct treatment is to manage the provider as a supplier and state your own responsibilities under the shared responsibility model. See Shared Responsibility in AI EMR Security Design.
No description of the interfaces
"Finance is out of scope" with nothing about what flows to finance. Audits ask how information leaving the narrowed boundary is controlled. One line each for what leaves and what enters avoids most findings here.
Assuming scope can simply be widened later
Extension involves the certification body and an additional audit. "Start small and widen next year" is workable but pays twice. Going one step wider at the first build is sometimes cheaper in total.
Dropping employment types on the organisation axis
Procedures written with permanent staff in mind leave out on-site contractors and dispatched workers — often the people closest to the data. State employment types explicitly in the organisation axis.
Healthcare Examples
A SaaS provider for healthcare institutions
The core is planning, development, operation, maintenance and support of the service. Keeping support inside matters: engineers really do access live patient data during incident investigation, so excluding support puts the most sensitive touchpoint outside the system.
Physically, name the development site and remote-work environments. Logically, include production, staging, the corporate network, and anywhere customer data may transit — the support file share, the ticketing system.
A PHR operator
Because data comes from individuals directly, the app, the backend and the enquiry desk form the core. Scope design interlocks with obligations under the personal information law, so settling the legal view first avoids rework. See ISMS for PHR Operators.
A SaMD developer
The ISMS scope coexists with the QMS (ISO 13485) scope. They need not coincide, but design and development fall under both. Keeping the document sets separate while making the touchpoints explicit is the workable pattern. See SaMD, ISMS and QMS.
A clinical trial systems company
Because integrity and audit trails are the heart of the business, the logical axis must reach beyond production to backups and log storage. Exclude them and most of your integrity risk treatment ends up outside the system.
Common ground when hospitals are your customers
Hospitals carry their own obligations under Japan's three-ministry guidelines and therefore require an equivalent standard of their suppliers. What they want to see is the whole of the service delivered to them. Reflecting that in the wording shortens procurement. See Three-Ministry Guidelines, Implementation Steps, and Scope Design for Healthcare Companies.
Conclusion
- Scope very nearly determines total project effort and is the costliest decision to reverse. Fix "to whom, to show what" first
- Draw boundaries on four axes — organisation, physical, logical, business. One axis alone leaves gaps
- Narrowing is legitimate, but the interfaces created by narrowing must be described
- Cloud is not "out of scope." Manage providers as suppliers and state your side of the shared responsibility model
- Name remote work and contract or dispatched staff explicitly; wording that diverges from reality draws findings
- Draft the certificate wording first and check it with sales and management — extending scope later means an extra audit
With scope fixed, the next task is inventorying the information inside it: Building an Information Asset Register, How to Run a Risk Assessment, and Writing an Information Security Policy.
Pottech supports ISMS certification with a focus on healthcare. Scope design changes conclusion depending on whether you know what customers actually look at. See ISMS Certification Support or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee (JISC)
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Personal Information Protection Commission, Japan
Note: interpretation of requirements and the handling of accreditation and certification are governed by the standard itself and by the publications of the accreditation and certification bodies, and may change with revisions.