If you're implementing ISO 27001, Clause 4 is where certification either gets grounded in reality or quietly goes off the rails. This guide explains exactly what the context of the organization requires, what you must document, which frameworks to use, and how to do it in a way that holds up under audit.
What is ISO 27001 Clause 4?
ISO 27001 Clause 4 formally titled "Context of the Organis ation" : is the first operational clause of the standard. It requires an organization to understand its environment before building any part of its information security management system. Specifically, it covers four areas: identifying internal and external issues that affect information security (4.1), understanding who has a stake in your ISMS and what they require (4.2), formally defining the boundaries of the ISMS (4.3), and establishing the ISMS as a managed system (4.4).
Clause 4 does not ask you to implement controls, that comes later. It asks you to understand your world well enough to make the right decisions about which controls matter and why.
Why Context Comes Before Controls
If you've read our guide to ISO 27001 Clauses 4–10, you'll know that ISO 27001 Clause 4 sits at the very beginning of the certification journey and for good reason. Before you can decide what to protect, you need to understand why it matters, who depends on it, and where it lives.
Clause 4 asks three foundational questions: What forces shape your organisation's information security environment? Who has a stake in how you manage it? And what, precisely, are you committing to protect?
The answers to those questions define the scope and direction of your entire ISMS. A weak or rushed context analysis will create gaps that auditors and attackers will eventually find.
Clause 4.1 — Internal and External Factors
ISO 27001 is a risk-based standard. Its Clause 4 borrows directly from ISO 31000:2018 (risk management), specifically its "establish the context" step. ISO 31000 defines risk as the effect of uncertainty on objectives. In practice this means your context analysis is not a background narrative, it is a structured risk input: internal capabilities and constraints, external pressures and the expectation of clients. That is exactly what Clause 4 does, applied to information security.
The standard requires organizations to identify internal and external issues that could affect the ISMS achieving its intended outcomes. A 2024 amendment (Amendment 1) added an explicit requirement to determine whether climate change is a relevant issue, something auditors now expect you to have considered and documented either as a live factor or a reasoned negative determination.
Internal factors to consider include: your governance structure and risk appetite, existing IT infrastructure and legacy systems, staff capabilities and turnover, company culture, ongoing mergers or restructuring, and how information flows between departments.
External factors include: applicable laws and regulations (GDPR, NIS2, sector-specific rules), market and competitive dynamics, geopolitical risks, supply chain dependencies, and the pace of technological change including AI-related threats.
Example: Internal issue in practice:
Issue: Legacy ERP system running unsupported software
Risk: Increased vulnerability exposure with no vendor patches available
Action: Logged as a risk input into Clause 6 assessment; owner and review date assigned
Frameworks that help:
- SWOT (Strengths, Weaknesses, Opportunities, Threats) is the simplest way to map both internal and external issues ISO 27001 in a single view — useful for workshops with senior management.
- PESTLE (Political, Economic, Social, Technological, Legal, Environmental) provides a structured lens for the external environment and ensures you don't overlook regulatory or macro-level forces.
- A Context and Issues Register — a maintained table of each issue, its owner, and when it was last reviewed — turns a one-off analysis into a living document.
Documented information: Clause 4.1 does not explicitly require a formal document. However, auditors will probe this area either through interviews or by checking your other documents for evidence that context was considered. A short register or summary is strongly recommended.
Clause 4.2 — Interested Parties and Their Requirements
Clause 4.2 requires you to identify the parties who have a stake in your ISMS and determine what they need from it. The 2022 version made one key addition explicit: you must also decide which of those requirements the ISMS will actually address and document that decision.
Typical interested parties include:
- Customers and clients (data protection expectations, contractual obligations)
- Regulators (GDPR supervisory authorities, NIS2 competent authorities, sector regulators)
- Employees (clear policies, personal data protection)
- Suppliers and cloud/SaaS partners
- Shareholders and board members (risk reporting, defined risk appetite)
- Your certification body (conformity to the standard)
- Insurance providers (security conditions tied to coverage terms)
A critical point: if a regulatory or contractual requirement mandates a control, that control must be included in your Statement of Applicability and implemented regardless of where it falls in your internal risk ranking. ISO 27001 Clause 4.2 creates binding inputs to your risk treatment process.
Good practice:
- Maintain an Interested Parties Register listing each party, their relevant requirements, and how each is addressed or formally excluded.
- Use a stakeholder power/interest matrix to prioritise whose requirements take precedence when obligations conflict.
- Revisit the register at every management review. Clause 9.3 explicitly lists changes in interested party requirements as a mandatory review input.
Documented information: Not explicitly required by the standard, but auditors expect to see it. An undocumented analysis is difficult to defend under scrutiny.
Build your Interested Parties Register in minutes.
Our free Clause 4 template includes a pre-structured Interested Parties Register, Issues Log, and Scope Statement, ready to fill in and present to your auditor.
Clause 4.3 — Defining the ISMS Scope
This is the one place in Clause 4 where documented information is mandatory. Failing to produce a written, approved ISO scope statement during a Stage 1 audit is a critical non-conformity.
The scope defines the boundaries of your ISMS: what it covers, what it excludes, and how it connects to activities outside those boundaries. It should be defined across five dimensions:
- People — which staff, roles, and contractors are in scope
- Processes — which business processes handle in-scope information
- Technology — systems, platforms, cloud environments, and networks
- Information — which data assets are being protected
- Location — offices, data centres, remote working arrangements
Scope must account for interfaces and dependencies. How in-scope activities connect to out-of-scope systems or third-party organisations. A cloud hosting provider, an outsourced payroll processor, or a shared development environment all create boundaries that need to be explicitly managed.
Exclusions are permitted but must be formally justified and must not create gaps in your ability to protect in-scope information. You cannot exclude Clauses 4–10 themselves; exclusions apply only to Annex A controls.
Once defined, the scope appears in your Scope Statement (the mandatory document), is referenced in your Statement of Applicability, and should be version-controlled and approved by senior management.
Clause 4.4 — The ISMS as a System
Clause 4.4 is often the shortest stop in Clause 4, but don't mistake brevity for low importance. It ties everything together: the context you've mapped, the stakeholders you've identified, and the scope you've drawn must function as a unified, managed system, not a folder of policies that nobody reads.
Think of it as the "so what" clause. The work done in 4.1 through 4.3 only has value if it actively shapes how you run, monitor, and improve your ISMS over time.
No additional documented information is explicitly required, but a process map or RACI showing how the ISMS elements connect is useful evidence of intent.
What to Document, and What Is Good Practice
Mandatory documented information under Clause 4:
- ISMS Scope Statement (Clause 4.3) — the only explicitly required document in this entire clause
Recommended artifacts that auditors expect and that make your life easier:
- Context and Issues Register a maintained log of internal and external factors, owners, and last review dates
- SWOT or PESTLE analysis to evidence that context was systematically assessed
- Interested Parties Register, listing each party, their requirements, and how each is addressed or formally excluded
- Stakeholder power/interest matrix to prioritise conflicting requirements
- Scope workbook or narrative explaining inclusions, exclusions, and their rationale
- Network or data flow diagrams evidencing the technological and physical boundaries
- RACI or process map showing how ISMS elements connect (supports Clause 4.4)
Start your Clause 4 context analysis today.
Most teams spend weeks on this. Our Clause 4 template gives you a pre-built Context Register, Interested Parties Register, and Scope Statement, structured exactly the way auditors expect to see them.
Where to Go Next
Clause 4 feeds directly into Clause 6 (risk assessment and treatment) and Clause 5 (leadership commitment and policy). The ISMS scope you define here sets the boundaries for every risk assessment, every control selection, and every audit finding that follows.
For a full view of what each clause requires you to build, document, and evidence from planning through to improvement, see our complete guide: ISO 27001 Clauses 4–10.