For ISO 27001 clause 4 you write down the internal and external issues that affect your security goals, the interested parties (customers, regulators, staff, suppliers) and what each requires of you, and then define the scope of your ISMS. Keep it to a page or two. The point is to feed risk assessment, not to produce a report.
What clause 4 contains
Clause 4 has four parts. 4.1 asks you to determine the internal and external issues relevant to your purpose and to the aims of the ISMS. 4.2 asks who the interested parties are, what they need, and which legal, regulatory and contractual requirements apply. 4.3 sets the scope and boundaries, considering those issues, those requirements and the dependencies on other organizations. 4.4 says you must establish, operate and continually improve the ISMS. These summaries follow a public guide to the standard.
Step 1: list issues, split in two
| Type | Examples to consider |
|---|---|
| Internal | Company size, remote work, rapid hiring, legacy systems, in-house or outsourced development |
| External | Customer security demands, regulation, threat activity against your sector, reliance on cloud providers |
Write one line on why each matters for information security. If you cannot, drop it.
Step 2: list interested parties and requirements
Start from who can hurt or help you. Customers who send security questionnaires. Regulators with data protection rules. Employees who handle data. Cloud and software suppliers. Insurers. Investors.
For each, record the requirement in plain words, such as "notify us of a breach within a stated time" from a contract, or "protect personal data" from a law. The standard also expects you to decide which of these become obligations you must meet. Ask counsel when a legal point is unclear.
Step 3: turn it into scope
Your scope statement should name the products, locations, teams and systems inside the ISMS, and say what is outside and why. Dependencies matter: if a cloud provider runs part of your service, say so and describe how you manage that relationship. For more on boundaries, see scoping before you start.
Step 4: connect it to risk
Every issue and requirement you listed should show up somewhere later: a risk, an objective or a control. A customer demand for encryption should lead to a control choice. Gaps between your list and your risk register are what an auditor tends to notice.
Step 5: review it on a schedule
Context changes. Put the page on the agenda of your management review, and update it when you launch a product, enter a market or change a major supplier.
Quick check
Do we need a formal register of interested parties?
The standard requires you to determine them and their requirements, not a particular format. A simple table is usually enough. Confirm with your certification body.
Is this the same as a risk assessment?
No. Context and interested parties are inputs to risk assessment, which is a later step in clause 6 and clause 8.
Safeguard's asset discovery and compliance automation can help show which systems and dependencies actually exist when you draw your scope. The scope decision is yours and your auditor's.
Sources
Last reviewed: 19 October 2026.
