ISO 27001 context of the organisation

ISO 27001:2022 clause 4 asks you to understand what shapes your information security before you protect anything. You identify internal and external issues (4.1), the interested parties and their requirements (4.2), write down the scope of your ISMS (4.3), and run the system as a set of connected processes (4.4).

The requirement in plain English

Clause 4 is the foundation every later decision rests on. An auditor reads it first because a risk assessment, a Statement of Applicability or a control only makes sense against a defined scope and a known set of expectations.

Issues (ISO 27001:2022 4.1). You determine the internal and external issues that affect whether your ISMS can achieve what it is for. External issues include your market, your customers’ expectations, the law and the threats you face. Internal ones include your size, your technology, your culture and your capacity. Since Amendment 1 of 2024 you must also decide whether climate change is one of them.

Interested parties (ISO 27001:2022 4.2). You determine who has a stake in your information security, what they require of you, and, new in the 2022 edition, which of those requirements the ISMS will address (ISO 27001:2022 4.2 c)). Customers, staff, regulators, investors, insurers and key suppliers are the usual interested parties. Their requirements include legal, regulatory and contractual obligations, which Annex A then asks you to keep track of (ISO 27001:2022 Annex A 5.31).

Scope (ISO 27001:2022 4.3). You set the boundaries of the ISMS, taking account of the issues, the requirements and the interfaces and dependencies between what you do and what others do for you. The scope must be available as documented information. It is the only part of clause 4 the standard says you must document.

The system (ISO 27001:2022 4.4). You establish, run, maintain and improve the ISMS, including the processes it needs and how they interact. The process wording is a 2022 addition.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

Take a 30-person software company selling a scheduling product to hospitals and clinics, hosted in one cloud region, with a small office and most staff working from home.

The scope statement is one paragraph and a short list. It names the product, the production cloud account, the corporate laptops and identity provider, the office and home working, and the teams inside it (engineering, customer support, operations). It names what is outside, such as the marketing website run by an agency, and says why. It lists the interfaces: the cloud provider, the payment processor, the payroll bureau. The wording matches the certificate the company wants.

The issues register holds 10 to 15 dated rows, each with a one-line effect on security: hospital customers demanding audit rights, a planned move to a second region, reliance on two senior engineers, a rise in phishing aimed at clinicians. One row records the climate change decision.

The interested parties register lists each party, what it requires, and whether the ISMS addresses it. NHS customers require evidence of security assurance; the ICO requires personal data security; investors require continuity. The operations lead owns both registers, reviews them before every management review, and updates them when something changes, such as a new market or a large new customer.

A one-page process map shows how risk assessment, change, incident handling, supplier review, internal audit and management review feed one another.

Evidence an auditor expects

Scope statement (required documented information): the auditor checks that it names boundaries, exclusions with reasons, and interfaces, and that it matches the certificate wording and the Statement of Applicability.
Issues register or equivalent: not mandated as a document, but the auditor asks how you identified issues and looks for a date and a link to risk.
Interested parties and their requirements: the auditor checks each requirement is either addressed by the ISMS or consciously left out, which is the 4.2 c) test.
Register of legal and contractual obligations: usually sampled against a real customer contract to see whether its security clauses appear.
Process map or equivalent: the auditor checks the processes named in it exist and have owners.
Management review minutes: the auditor looks for changes in issues and interested parties being reviewed (ISO 27001:2022 9.3).

Common mistakes

A scope that leaves out what customers are buying

Some organisations scope the ISMS around head-office IT because it is tidy, then sell a product that runs outside it. A customer reading the certificate gets no assurance about the service they use. Scope around the information and services customers rely on, then add the rest when you are ready.

Cloud providers missing from the interfaces

When a scope says nothing about the cloud provider, the supplier and cloud controls in the Statement of Applicability often get excluded as “not applicable”. The auditor then finds production data held by a third party with no supplier review. List the interfaces in the scope, and the supplier controls follow.

Interested parties without requirements

A list of names (customers, staff, regulator) satisfies nobody. The 2022 wording asks for each party’s requirements and a decision on which the ISMS addresses. Add a column for each and fill it in.

Context written once and never touched

Issues registers often carry the date of the first certification project and nothing since. Surveillance auditors notice a register that never changes while the business plainly has. Review it before each management review and date the review even when nothing moved.

Silence on climate change

Since 2024 auditors ask whether you considered it. A missing answer hands the auditor a finding; a recorded “considered, relevant only to hosting availability, covered by the continuity plan” closes it.

How Sted helps

Management-system registers (scope, interested parties, obligations, issues, objectives, risks and opportunities, processes) are edited by administrators; the first three are drafted from your onboarding answers and the rest start empty.
When onboarding finishes, Sted drafts the management systems, scope, interested parties and compliance obligations registers from your answers, labels each drafted row “Derived from your onboarding answers” until someone edits it, and never overwrites an edited row; issues, objectives, risks and opportunities, and processes start empty, every register hangs off a management system, nothing is deleted, and only issues, objectives and risks can be retired.
Summary shows nine profile cards of what Steward has learnt (an unanswered question reads “Not yet captured”), strips counting your standards, audit readiness (administrators only) and framework, a Statement of Applicability card per eligible standard, the registers that have rows, and last a collapsed Generation history for administrators and Policy and Process Owners; it has no generate button.

Sted drafts these registers from your onboarding answers. It does not decide your scope; an administrator reviews and edits each row before an auditor relies on it.

ISO 27001: the hub, and how clause 4 feeds the rest of the loop.
Risk assessment and treatment: the next step, where issues and requirements become risks.
The Statement of Applicability: where scope decisions show up as control exclusions.
Management-system registers: where Sted keeps scope, interested parties, obligations and issues.
Interested parties: the term, and how it differs from stakeholders in general.

Frequently asked questions

Do I have to write down my interested parties and issues?

No, clause 4 only requires the scope as documented information. In practice an auditor tests clauses 4.1 and 4.2 by asking how you know your issues and stakeholders, and a short, dated register is the quickest answer. Without one, you rely on interviews going well.

Can a fully remote company put physical security out of scope?

Not entirely. With no office, the scope still includes the laptops, home working and any paper your people handle, so several physical controls still apply to them. What you can usually exclude is protection of premises you do not have, with that reason recorded.

Do we have to say anything about climate change?

Yes, since Amendment 1 of 2024 you must decide whether climate change is a relevant issue for your ISMS. For many service businesses the answer is a recorded judgement, such as the availability risk of a cloud region in extreme weather, rather than a new programme.