Clause 4 is where ISMS work begins — and where most organisations stall. The reason is simple: "understand the organisation and its context" is not, as written, a work instruction.
It is also the clause you cannot easily walk back. The scope you set here determines audit effort, audit fees, and three years of operational load. Draw it too wide and the organisation runs out of breath maintaining it; draw it too narrow and a customer tells you the certificate does not cover what they are buying.
This article translates Clause 4 into practice: what to identify, what to document, and what auditors ask — with healthcare examples. For the whole standard, see What Is an ISMS (ISO/IEC 27001)?.
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.
What This Clause Actually Asks For
Clause 4 has four parts. Restated as practical questions:
1. Understanding the organisation and its context
Identify the features of your business environment that could affect the outcome of your ISMS — external (customer requirements, law, industry guidelines, technology trends, cloud dependency) and internal (business model, structure, headcount, legacy systems, culture).
What belongs here is your situation, not general commentary. "Cyberattacks are increasing" could be written by anyone and helps neither operation nor audit. "We provide SaaS to hospitals and are asked, as a procurement condition, to explain alignment with Japan's three-ministry guidelines" is your situation.
2. Understanding the needs and expectations of interested parties
Who has requirements of your ISMS, what are they, and which of them will the ISMS address? Candidates: customers, patients and end users, employees, shareholders, regulators, suppliers, the certification body.
3. Determining the scope
From 1 and 2, decide which organisations, activities, sites and systems the ISMS applies to, and document it. Where things sit outside, you must be able to explain the boundaries and the interfaces across them.
4. Establishing the ISMS itself
Establish, operate, maintain and improve the management system within that scope. This reads almost as a declaration, but it is the premise everything from Clause 5 onward rests on.
The point is that 1–3 are one chain of reasoning, not three separate tasks. Context and interested parties produce the scope; the scope determines what risk assessment (Clause 6) covers. Break the chain and every later clause loses its foundation.
What You Produce in Practice
Clause 4 generates few documents — but every later clause refers back to them.
| Deliverable | Purpose | Who approves |
|---|---|---|
| Register of external and internal issues | Identify what in the environment affects ISMS outcomes; feed risk assessment | ISMS manager (reviewed at management review) |
| Register of interested parties and their requirements | Define whose requirements the system serves; prevent gaps in legal and contractual obligations | ISMS manager (checked by legal and sales) |
| ISMS scope statement | Define what is certified; explain boundaries and interfaces | Top management |
| Scope rationale memo | Record why this scope, and why anything excluded was excluded | ISMS manager |
| Org chart, site list, system diagram | Give the scope a concrete physical and logical outline | ISMS manager |
The scope statement is the source of the wording printed on the certificate. It is normally registered company name + the activities covered + the sites, and that wording is what your customers read. That is why sales should be in the room when it is decided.
As a practical benchmark, the issues and interested-party registers work best at 15–30 rows. A several-hundred-row exhaustive list will not survive to the next management review.
Where It Goes Wrong
Assuming "whole company" is the safe answer
Company-wide scope is an option, not a default correct answer. It puts every site, department and activity into audit, increasing auditor-days and internal audit load. Including back-office-only sites and departments that barely touch information assets adds effort without adding assurance.
Conversely, what a customer is checking is whether the work they outsource to you falls inside the scope. If it does, company-wide is not required.
Drawing it so narrowly that it cannot be explained
"Engineering only" makes boundaries hard to justify. Joiner–leaver processes owned by HR, account administration owned by IT, physical entry owned by facilities — all directly bear on engineering's information security. Declaring them out of scope will be challenged. Cutting along information flows rather than departmental lines produces a more coherent boundary.
A context register full of generalities
A register with no company-specific line in it signals to an auditor that Clause 4 was filled in for form's sake.
Interested-party requirements with no law in them
Personal information protection law, the Medical Care Act, the PMD Act, industry guidelines. If applicable legal and regulatory requirements are not captured here, they will be missing from Clause 6 risk assessment and Clause 8 operation too. Build the legal register in Clause 4 and maintain it thereafter.
Treating cloud and suppliers as simply "out of scope"
Cloud services and suppliers sit outside your organisational boundary, but the information handled there remains your responsibility. You cover it through boundary and interface description plus supplier management (organisational controls in Annex A.5). See Supplier Security Management and Demarcating Responsibility.
What Auditors Look At
Stage 1 (documentation review) examines the Clause 4 outputs together.
| Aspect | What is asked |
|---|---|
| Clarity of scope | Can a third party tell what is in and what is out? |
| Boundaries | How are interfaces with out-of-scope organisations and systems managed? |
| Consistency of rationale | Does the scope follow from the context and interested-party analysis? |
| Justification of exclusions | Is each exclusion reasonably explained? |
| Maintenance | Who reviews the registers, and when? |
| Match with reality | Do the documented scope and the actual organisation, sites and systems agree? |
The most common finding is the last one: work happening at a site not named in the scope statement, or documents not updated after a reorganisation. Scope is not decided once — it is reviewed at every reorganisation, new business line and site move.
See What Stage 1 Audits Look At.
Healthcare Examples
A SaaS provider serving hospitals
Scope naturally reads as "planning, development, operation and maintenance of the service," covering every site involved — because that is precisely what the hospital has outsourced.
Interested-party requirements then include:
- Customers (hospitals): safeguards required by the three-ministry guidelines, explicit demarcation of responsibility, disclosure of sub-processors
- Patients and users: that medical information is not used beyond its purpose
- Regulators: handling as special care-required personal information
- Cloud providers: fulfilling the customer-side share under the shared responsibility model
Capturing the three-ministry guidelines explicitly as an interested-party requirement keeps later clauses consistent. See Integrating ISMS Documents with the Three-Ministry Guidelines and the existing Three-Ministry Guidelines explainer.
A PHR operator
PHR takes data directly from the individual. The primary interested party is the user, whose requirements are "not used beyond what I consented to" and "I can see and delete my data." Practically, scope should cover app, backend and customer support as one unit. Leaving support outside makes the path by which agents touch personal data impossible to explain.
A clinical trial systems company
Trial sponsors and regulators join the interested-party list, bringing ER/ES guidance and data integrity into requirements. Scope must include the systems holding the audit trail and the team that operates them.
A SaMD developer
A separate QMS (ISO 13485) scope already exists, so the relationship between the ISMS scope and the QMS scope must be settled first. If they disagree, design control records end up belonging to neither documentation system clearly.
See Scope Design for Healthcare Companies and Defining ISMS Scope.
Conclusion
- Clause 4 is one chain: context → interested parties → scope. Break it and later clauses lose their basis
- Three core deliverables: issues register, interested-party register, scope statement. Top management approves the scope statement, which becomes the certificate wording
- Wider is not safer. The test is whether the work your customers outsource is inside
- A context register of generalities is form-filling. Write what is specific to you
- The most common finding is documented scope diverging from reality. Build review into every reorganisation
- In healthcare, capture the three-ministry guidelines and regulatory expectations explicitly as interested-party requirements
The scope set here becomes policy and roles in Clause 5: Leadership, and the subject of risk assessment in Clause 6: Planning, followed by Clause 7: Support, Clause 8: Operation, Clause 9: Performance Evaluation and Clause 10: Improvement.
Pottech supports ISMS certification with a focus on healthcare. Because scope must be set against both customer requirements and operational load, involving us early avoids rework. See ISMS Certification Support for scope and pricing, 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
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.