ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The ISO 27001 context of the organization is clause 4.1, the first requirement in the standard and the one most implementers treat as a formality before moving on to risk. That is a mistake with a delayed cost. Clause 4.1 is the only requirement in clause 4 that demands no documented information at all, yet three later clauses depend on its output — so when it is done badly, the nonconformity lands somewhere else entirely, usually in your scope or your risk assessment, months later.
This guide covers what the ISO 27001 context of the organization actually asks for, how it differs from clause 4.2, the climate change determination that most context registers still get wrong, and exactly where the output is consumed.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
Clause 4.1 of ISO/IEC 27001:2022 requires you to determine the external and internal issues that are relevant to your purpose and that affect your ability to achieve the intended outcomes of your information security management system. That sentence carries two filters, and both matter:
The verb in the ISO 27001 context of the organization requirement is determine. The standard does not say analyse, document, approve or publish. ISO/IEC 27001:2022 is 19 pages and names seven documents plus six categories of records as mandatory; a context register is not among them. Clause 4.1 never uses the phrase “available as documented information”, which clause 4.3 does use for the ISMS scope.
That is the trap. Because the ISO 27001 context of the organization requires no document, teams skip the write-up — and then cannot show the determination happened when an auditor traces the scope statement backwards.
The ISO 27001 context of the organization and clause 4.2 are routinely collapsed into one spreadsheet, and the merge hides a real difference. Clause 4.1 deals with issues — conditions in your environment. Clause 4.2 deals with requirements — things specific parties expect of you.
| Aspect | Clause 4.1 — Issues | Clause 4.2 — Interested parties |
|---|---|---|
| What you determine | External and internal issues relevant to ISMS outcomes | The interested parties, and their relevant requirements |
| Typical entries | Regulatory change, threat landscape, remote working, legacy systems, skills shortage | Customer security clauses, regulator duties, staff expectations, insurer conditions |
| Documented information required | None stated | None stated in 4.2 — but control A.5.31 requires legal, statutory, regulatory and contractual requirements to be identified, documented and kept current |
| Added in the 2022 edition | No change of substance | Item (c): which of these requirements will be addressed through the ISMS |
| Feeds into | 4.3 scope, 6.1.1 planning, 9.3.2 review | 4.3 scope, 6.1.1 planning, 9.3.2 review |
The practical consequence: an issue needs no owner and no action. A requirement usually needs both. Mixing them produces a register where half the rows are actionable and half are weather reports, and auditors pick at exactly that seam. Our ISO 27001 interested parties guide covers the 4.2 side, including why A.5.31 is the clause that actually creates a documented obligation.
The newest addition to the ISO 27001 context of the organization arrived in February 2024, when ISO added identical climate text to around 31 management system standards. For information security it arrived as ISO/IEC 27001:2022/Amd 1:2024, “Climate action changes” — listed on ISO’s own catalogue page at CHF 0, so there is no excuse for not reading it. Clause 4.1 gained one sentence: the organization shall determine whether climate change is a relevant issue. Clause 4.2 gained a note that relevant interested parties can have requirements related to climate change.
Two things about this addition are consistently handled wrong.
First, it is a determination, not a mention. A PESTLE row that lists “climate” under Environmental is not a determination. The auditor is looking for a recorded conclusion — relevant, or not relevant — with the reasoning behind it and a date. “Not relevant” is a perfectly acceptable answer for a software business with no owned data centre, provided somebody reasoned it and recorded it.
Second, a determination of “relevant” that never reaches clause 6.1 planning is decorative. If flood risk to your primary site is a relevant issue, it should appear in the risk assessment and, where treated, in the risk treatment plan. A context register that says “relevant” while the risk register says nothing is an internal contradiction an auditor can read in two minutes.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
Note also that the amendment is additional content published alongside the standard rather than folded into the 2022 text, so a 2022 PDF bought before 2024 will not contain the sentence. The requirement still applies.
This is the part that explains why the ISO 27001 context of the organization rarely produces a finding of its own. Three separate requirements take 4.1 as an input, and each one fails visibly when the context work was thin.
| Clause | What it takes from 4.1 | How a weak 4.1 shows up |
|---|---|---|
| 4.3 Determining the scope | The 4.1 issues, the 4.2 requirements, and interfaces and dependencies with other organizations | A scope statement nobody can justify; boundaries drawn around convenience rather than risk |
| 6.1.1 Planning — general | The 4.1 issues and the 4.2 requirements, when determining risks and opportunities | A risk register that is all technical threats and no business context — no supplier concentration, no regulatory change, no skills gap |
| 9.3.2 Management review inputs | Changes in external and internal issues relevant to the ISMS | Management review minutes with nothing to say under that agenda item, year after year |
The 2022 edition sharpened this. Clause 9.3.2 added changes in the needs and expectations of interested parties as a separate mandatory review input, and clause 4.4 gained a requirement covering the ISMS processes and their interactions. Both make the context work harder to fake. See our ISO 27001 scope guide for how 4.1 feeds the scope statement, and the ISO 27001 management review guide for the 9.3.2 agenda.
There is no prescribed format for recording the ISO 27001 context of the organization. What survives an audit is a short table, maintained, with a determination date and a named owner for the review — not a twenty-page environmental essay. A workable structure:
| Category | Example issues | Why it affects ISMS outcomes |
|---|---|---|
| Legal and regulatory (external) | Sector regulation, breach notification duties, data transfer rules | Drives mandatory controls and reporting clocks |
| Threat landscape (external) | Ransomware against your sector, supply chain compromise, credential stuffing | Shapes risk likelihood and control selection |
| Market and customer (external) | Customers requiring certification, competitor assurance posture | Sets certification scope and timelines |
| Technology (external) | Cloud concentration, vendor end-of-support, AI tooling adoption | Changes the asset inventory and the attack surface |
| Climate (external) | Physical risk to sites, energy and cooling constraints | Required determination; may affect availability |
| Structure and change (internal) | Acquisitions, reorganisation, new product lines, offshoring | Moves scope boundaries and ownership |
| People and capability (internal) | Security skills gaps, turnover, reliance on key individuals | Affects whether controls actually operate |
| Technical estate (internal) | Legacy systems, shadow IT, technical debt, remote working | Creates vulnerabilities that controls must address |
| Culture and resourcing (internal) | Security budget, leadership engagement, risk appetite | Determines treatment capacity and escalation |
Three habits make the difference. Keep rows specific enough to argue with — “cyber threats are increasing” is not an issue, “our two largest customers now require evidence of supplier security assessment” is. Review it on a cycle that matches the business, and record the review, because clause 9.3.2 will ask for changes. And when an issue is material, carry it into the risk assessment rather than leaving it stranded in the context register; our ISO 27001 risk assessment guide covers that hand-off.
One more thing worth saying plainly: the ISO 27001 context of the organization is not a one-off exercise. Clause 6.3, new in 2022, requires changes to the ISMS to be planned, and a shift in context is exactly such a change. See our ISO 27001 change management guide for how that works in practice.
No. The ISO 27001 context of the organization carries no documented information requirement, and a context register does not appear in the standard’s list of mandatory documents. But you must be able to demonstrate the determination was made, and in practice the cheapest evidence is a short written register. “We know our context” is not evidence an auditor can sample.
Clause 4.1 identifies conditions; clause 6.1.2 identifies risks to information. Context is the input, not the assessment. A relevant issue such as “heavy reliance on one cloud provider” becomes one or more risks with likelihood, impact and an owner once it reaches 6.1.2.
No. You have to determine whether it is, and record the determination either way. A reasoned “not relevant” is acceptable. What is not acceptable is silence, or a register that says relevant while the risk assessment ignores it entirely.
ISO/IEC 27001:2022 states no review frequency for the ISO 27001 context of the organization. Annual alignment with management review is the common convention, and significant business change — an acquisition, a new jurisdiction, a major system migration — should trigger an out-of-cycle update. Never present annual review as a requirement of the standard, because it is not one.
The substance of clause 4.1 did not change in 2022. What changed around it: clause 4.2 gained item (c), clause 4.4 gained the processes-and-interactions requirement, clause 6.3 planning of changes is wholly new, and clause 9.3.2 gained the interested-parties input. The climate sentence arrived separately, in 2024.
The ISO 27001 context of the organization is twenty minutes of thinking and an afternoon of writing, and it determines the quality of three later clauses. Teams that rush it pay for it at stage 1, when the auditor asks why the scope is drawn where it is and there is no answer on file. Teams that do it properly find the risk assessment writes itself, because the business context is already on the page.
Our ISO 27001 Toolkit provides 165 templates mapped to ISO/IEC 27001:2022, including the context and interested parties records, the ISMS scope statement, the risk assessment and treatment set, and the management review pack — with the climate determination built in rather than bolted on. It is $99 as a one-off purchase. If you want the clause-by-clause picture first, start with our complete guide to ISO 27001.
November 1, 2026
October 31, 2026
October 31, 2026
October 30, 2026
October 30, 2026