Clause 4 is the first set of requirements in ISO/IEC 27001:2022, and the one teams finish fastest. Someone writes a page of strengths and weaknesses, lists "customers, regulators, employees" as interested parties, and moves on to the controls.
Auditors read it differently. Clause 4 is where the ISMS states what it is for and who it answers to. Everything after it, from scope to risk to management review, is meant to follow from what you wrote here. A thin clause 4 shows up later as a risk register that ignores your contracts, or a scope that does not match what you sell.
This article covers what each part of clause 4 requires, how to record it in a form that does work later, and what certification auditors tend to test.
What clause 4 contains
Clause 4, "Context of the organization", has four parts.
4.1 Understanding the organization and its context. Determine the external and internal issues that are relevant to your purpose and that affect your ability to achieve the intended outcomes of the ISMS.
4.2 Understanding the needs and expectations of interested parties. Determine the interested parties relevant to the ISMS, their relevant requirements, and which of those requirements the ISMS will address.
4.3 Determining the scope of the ISMS. Set the boundaries and applicability of the ISMS, considering 4.1, 4.2, and the interfaces and dependencies with other organizations. The scope must be available as documented information.
4.4 Information security management system. Establish, implement, maintain, and continually improve the ISMS, including the processes it needs and how they interact.
Amendment 1 to ISO/IEC 27001:2022, published in 2024, added climate change to clause 4. Under 4.1 you must determine whether climate change is a relevant issue, and a note to 4.2 says interested parties can have requirements related to climate change. For many software companies the honest answer is that it is a minor issue, mainly through effects on facilities or providers. The requirement is to have considered it, and to be able to show that you did.
Scope gets its own article later in this series. The rest of this one covers 4.1 and 4.2, which feed it.
Clause 4.1: issues, not a strategy document
An "issue" in clause 4.1 is any condition, inside or outside the organization, that could affect what the ISMS is trying to achieve. A note to the clause points to ISO 31000 for further guidance on establishing context.
External issues usually come from a few predictable places:
The markets and customers you sell to, and the assurance they expect
Laws and regulations that apply to your data or your sector
Your reliance on cloud and software providers
The threats relevant to your type of business
Economic and competitive pressure that affects security investment
Internal issues are about the organization itself:
Structure, size, and rate of growth or change
Where staff work, and on which devices
The technology stack, including legacy systems and technical debt
Security skills available in house
Culture and the priority leadership gives to security
The standard does not explicitly require clause 4.1 to be documented. In practice you will write it down anyway, because an auditor cannot verify a determination that exists only in someone's head. A short register, with one line per issue, whether it is internal or external, and where the ISMS addresses it, does more work than a long narrative.
Say a hypothetical 60-person SaaS company sells scheduling software to hospitals. An external issue is that its buyers expect a security review before every contract. An internal issue is that most engineers work remotely on company laptops. Each line points somewhere concrete: the first to supplier assurance and the Trust Center, the second to endpoint and remote working controls.
Clause 4.2: interested parties and their requirements
Clause 4.2 asks for three determinations, in order:
Which interested parties are relevant to the ISMS. An interested party is anyone who can affect, be affected by, or perceive themselves to be affected by your decisions or activities.
What their relevant requirements are. A note to the clause says these can include legal and regulatory requirements and contractual obligations.
Which of those requirements the ISMS will address. This third step was added in the 2022 edition.
The third step matters. Not every expectation a party holds belongs in the ISMS. A customer's requirement for a contractual uptime target is a service level matter that may sit outside it; their requirement that you notify them of a security incident within a contractual window belongs inside it. Writing down which side each requirement falls on is what makes the list useful.
A register for clause 4.2 needs only a few columns:
| Interested party | Requirement | Source | Addressed by the ISMS? | Where |
|---|---|---|---|---|
| Enterprise customers | Notification of security incidents within the contractual window | Master services agreement | Yes | Incident response procedure |
| Data protection regulators | Breach notification under applicable data protection law | Statute | Yes | Incident response procedure, legal register |
| Employees | Clear rules for acceptable use of company devices | Employment terms | Yes | Acceptable use policy |
| Investors | Assurance that security risk is understood at board level | Shareholder agreement | Yes | Management review |
| Cloud provider | Use of services within its acceptable use terms | Provider terms | Yes | Supplier management |
The rows above are illustrative. Yours should come from your actual contracts, the laws that apply to you, and conversations with the people who own those relationships. Sales, legal, and HR usually know more about interested party requirements than the security team does.
How clause 4 feeds the rest of the ISMS
Clause 4 is an input, so the test of a good one is whether it shows up downstream. Auditors trace these links.
Scope (4.3). The scope must take account of the issues and requirements you identified. If a contract requires a service to be covered and the scope leaves it out, expect a question.
Risks and opportunities (6.1.1). When planning the ISMS, you consider the issues from 4.1 and the requirements from 4.2 to determine the risks and opportunities that need addressing.
Legal and contractual controls. Annex A control 5.31 asks you to identify legal, statutory, regulatory, and contractual requirements relevant to information security. Your 4.2 register is a natural starting point.
Management review (9.3). Changes in external and internal issues, and in the needs and expectations of interested parties, are both required inputs to the management review.
That last link is how clause 4 stays current. If the management review agenda asks "what changed in our context and in what our interested parties need", the registers get revisited at least once per review cycle.
What auditors look for
During a certification audit, clause 4 is usually examined early, often in the document review at stage 1. The common questions are predictable.
Can you show how you determined the issues and interested parties, and who was involved?
Do the requirements in your register match the contracts and laws the auditor can see elsewhere in your records?
Is it clear which requirements the ISMS addresses and which it does not?
Can you point from each relevant requirement to the policy, control, or process that handles it?
When did you last review it, and what changed?
The common weaknesses are equally predictable. Registers written once for the audit and never touched again. Interested parties listed by category with no requirements attached. Issues that are generic enough to apply to any company, which tells the auditor the exercise was done from a template. A contract signed last quarter with new security terms that the register does not mention.
Keeping it proportionate
Clause 4 does not need to be long. For a small organization, a page of issues and a table of a few dozen interested party requirements is enough, if each line is specific and each points somewhere. What it cannot be is static, since the management review requires you to consider what changed.
If you are planning a first certification, build clause 4 before the risk assessment, not after, because the risk assessment depends on it. The first audit timeline shows where it sits in the sequence, and what an ISMS is, in plain terms covers how clauses 4 to 10 fit together. The ISO 27001 framework page summarizes the full set of requirements.
How TrustLynce helps
TrustLynce tracks customer commitments against the controls that meet them, so contractual requirements from clause 4.2 stay linked to the ISMS as agreements change. The risk register can reference those same issues and requirements when you assess risks under clause 6.