The first obstacle in any ISMS project is where to draw the scope. Whole company, one business unit, which sites? The reason this is hard is straightforward: a wider scope means higher audit fees and heavier ongoing operation, while a narrower one risks not being the proof your customers are asking for.
In healthcare the decision gets harder still. A company may run a hospital-facing SaaS alongside a general business tool, mix contract development with its own product, or split environments between those that hold medical data and those that do not. It is also common to draw the boundary by business line on paper and then find that the same engineers work on both sides of it.
This article covers how healthcare companies should design scope in practice, and which line on the certificate customers actually read. General scope-setting is covered in Defining ISMS Scope; here we stay on the healthcare-specific concerns.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) and the publications of accreditation and certification bodies. Confirm any scope decision with your certification body.
Scope Is a Declaration of What You Will Show at Audit
The standard requires you to determine the boundaries and applicability of the ISMS and document them as scope. In practice you decide four things.
| What you decide | Examples | Healthcare pitfall |
|---|---|---|
| Organisational unit | Whole company / a division / a subsidiary | Carving out the medical business leaves shared corporate functions outside |
| Business and services | "Planning, development, operation and maintenance of hospital-facing SaaS" | Omitting "maintenance" leaves out exactly what hospitals ask about |
| Sites | Head office / development site / remote work | Fully remote firms have no real "site", leaving home working ambiguous |
| Systems and facilities | Development, production, corporate IT, cloud | Production blurs into the cloud provider's responsibility and the boundary cannot be explained |
Scope is an external declaration that "this is what we hold under management." An incident outside scope does not invalidate the certificate, but to a customer that area is simply unproven. Conversely, everything inside scope must be evidenced with operating records at audit.
The standard also requires you to consider dependencies you do not control — cloud services, suppliers. "It is in the cloud, so it is out of scope" does not work. Treat cloud environments as under your management and be able to explain the demarcation with the provider. We cover that from the buyer's side in Demarcating Responsibility.
When Medical and Non-Medical Businesses Coexist
The most common healthcare pattern. Three options.
① Whole company
Simplest and cheapest to explain. You can say "we are certified company-wide," which speeds up procurement checks. The cost is that the same procedures, training, and audits apply to divisions that never touch medical data, spreading operational load across the whole organisation.
② Only the business that handles medical data
Lower audit fees and lighter operation — but only if the boundary can be explained technically and organisationally. If the same engineers work on both products, and both share one Slack workspace and one GitHub organisation, no real boundary exists. To claim one, there must be actual separation in accounts, networks, repositories, or physical access.
③ Start narrow, widen later
A realistic path: certify a limited scope in year one, then widen at recertification once operation is stable. Extension requires additional audit, so compare across three years. See The Full Cost of ISMS Certification.
| Situation | Recommended | Why |
|---|---|---|
| Under 50 staff with no separation between businesses | ① Whole company | Explaining a boundary costs more than covering everything |
| Medical business is a separate division or subsidiary | ② Business-limited | The boundary is visible on the org chart |
| Medical business is early-stage and still changing shape | ③ Phased | Fixing scope too early creates change costs |
| Non-medical side is contract development with varied demands | ① Whole company | Every business ends up being asked for proof anyway |
How Far to Extend Across Development, Operation, and Support
This is where judgement diverges most. If you supply systems or services to hospitals, customers care about far more than development.
| Stage | Need to include | Key consideration |
|---|---|---|
| Planning and requirements | Medium | Include if customer medical data arrives at this stage |
| Design and development | High | Source code, development environments, third-party libraries |
| Testing | High | Whether production data is reused is always checked |
| Release and change management | High | Who can change production is a central audit topic |
| Production operation and monitoring | High | Where medical data actually lives; excluding it guts the proof |
| Maintenance and incident response | High | Access paths to production during incidents are the biggest risk |
| Customer support | Medium–High | Mandatory if support staff can see patient information |
| Sales and marketing | Low–Medium | Can sometimes be excluded if only CRM data is involved |
Testing and maintenance are the real dividing line. Copying production data into test, and engineers connecting directly to the production database to diagnose faults, are asked about on almost every hospital check sheet. Presenting a certificate that excludes them invites immediate follow-up questions.
Support is genuinely situational. If first-line intake is outsourced and scripted so that no patient information is seen, treating it as supplier management and leaving it out of scope is defensible — but you will be asked for the supplier management records. See Supplier Security Management.
What Customers Read on the Certificate
An ISMS certificate typically carries the following.
| Item | Why customers read it |
|---|---|
| Organisation name | Must match the contracting entity — subsidiary/parent mismatches are common |
| Registered scope | Whether the service being bought falls inside the wording. The most scrutinised line |
| Standard applied | ISO/IEC 27001:2022 or an older edition |
| Registration number | Used to verify the entry in the accreditation body's register |
| Accreditation symbol | ISMS-AC or an overseas accreditation body |
| Validity | Whether it is current, and when recertification falls |
What a procurement officer actually does is check whether the service they are buying can be read out of the registered scope wording. If it says only "planning and development of information systems," it proves nothing about operation or maintenance. In hospital procurement, that single line determines how many follow-up questions arrive.
Three practical notes on wording:
- Decide whether to name the service or describe the business type. Naming is clearer but forces a scope change every time the product is renamed
- List the stages exhaustively — "planning, development, operation, maintenance and support" — so customers can see their concern covered
- Check how sites are expressed. Fully remote organisations commonly register the head office address only and manage remote working through procedures
On certification as a condition of trade, see When ISMS Becomes a Procurement Requirement. For what hospitals ask suppliers, see Security Check Sheets for Vendors.
What Scope Determines Downstream
Scope directly sets the volume of work that follows. Fixing it fixes:
- The asset inventory — every information asset touched by in-scope business
- The risk assessment — everything in the inventory
- Statement of Applicability decisions — whether physical controls can be excluded depends on whether sites are in scope
- Training population — all staff in in-scope departments
- Internal audit coverage — every in-scope department and stage, once per cycle
The SoA depends on scope most strongly of all. How a fully remote organisation with no office treats physical controls, or how a company with only cloud production explains server-room controls, turns on how scope was worded. See Writing the Statement of Applicability.
If you supply hospitals, scope also interacts with Japan's three-ministry guidelines. If the subject of your guideline accountability and your ISMS scope diverge, you will rebuild the hospital-facing explanatory documents from scratch. See Integrating ISMS Documents with the Three-Ministry Guidelines.
For multi-tenant healthcare SaaS, tenant boundary design connects directly to how scope is explained — see ISMS for Healthcare SaaS: Multi-Tenant Risk.
Conclusion
- Scope is an external declaration of what you hold under management; anything outside it is unproven from a customer's point of view
- Carving out only the medical business requires real separation in accounts, networks, repositories, or physical access
- Among stages, testing and maintenance are the dividing line — reuse of production data and direct production access are always questioned
- Customers read the registered scope wording; whether their service and stage can be read from it decides how many questions follow
- Scope simultaneously fixes the asset inventory, risk assessment, SoA, training, and internal audit population — wider scope means heavier annual operation
- If three-ministry compliance is on the horizon, align the subject of that accountability with ISMS scope from the start
Pottech supports ISMS certification with a focus on healthcare, beginning with scope design shaped around your business structure and your customers' demands. We supply templates for procedures, registers, and training, and lead dealings with the certification body.
See ISMS Certification Support for scope and pricing, or contact us. For the overall picture, see What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: the adequacy of a scope definition is determined by the certification body, and certificate layouts differ between bodies. Interpretation of the requirements is governed by the standard and the publications of the accreditation and certification bodies.