ISO 27001 · CLAUSE 4.1
The clause runs to a few lines and asks for no document at all. That combination is why most teams get it wrong in both directions at once, writing too much and deciding too little.
TL;DR
Clause 4.1 asks you to determine the external and internal issues that matter to your purpose and affect whether your ISMS does its job. The work is the deciding, not the writing.
- Clause 4.1 requires no documented information. Only 4.3, the scope, has to exist as a document. Keep a register anyway, because it is the cheapest way to show an auditor the determination happened.
- Three later clauses consume the output: 4.3 scope, 6.1 risk, and 9.3 management review. If your register fed none of them, it is decoration.
- Amendment 1:2024 added one sentence: “The organization shall determine whether climate change is a relevant issue.” Registers written before 2024 do not answer it.
- Write issues, not topics. “Cloud” is a topic. “Production data sits in a US region while three of our five biggest prospects need Canadian residency” is an issue. Something has to happen about it.
- Generic is the failure mode. If a competitor’s name could go on your register unchanged, it tells your auditor nothing and tells you less.
- Canadian external issues moved this year. Bill C-8 received Royal Assent on 16 June 2026, enacting the Critical Cyber Systems Protection Act.
Sources: ISO/IEC 27001:2022 · IAF and ISO joint communiqué · Public Safety Canada
What Clause 4.1 asks for #
ISO/IEC 27001 is a copyrighted standard, so this article paraphrases rather than reproduces it. Buy the text before you build against it.
Clause 4.1 sits under “Context of the organization”. It tells you to determine your external and internal issues. Two filters apply. An issue has to be relevant to your purpose. It also has to affect whether your information security management system achieves what it is meant to. Teams drop the second filter.
- External issues. Anything outside the organization that bears on the ISMS. Law, buyers, suppliers, cloud providers, attackers, technology change.
- Internal issues. Anything inside it. What you sell, how you build, where data lives, who works there, how decisions get made, how much runway you have.
- The filter. Relevant to your purpose, and affecting the ISMS outcome. Most registers skip this. They list whatever the template suggested.
Amendment 1:2024 then adds one sentence to the clause. The same sentence went into every management system standard it touched. “The organization shall determine whether climate change is a relevant issue.” A companion note lands in 4.2. Interested parties can have climate requirements of their own. The IAF and ISO published both on 23 February 2024.
The part nobody reads: Clause 4.1 needs no document #
ISO 27001 names its documented information requirements where it wants them. Clause 4.3 carries one, because the scope has to be available as documented information. Clause 4.1 carries none. Neither does 4.2.
So there is no such thing as a mandatory “context of the organization” document. Templates that tell you otherwise are selling you a template.
Here is the catch. An auditor cannot test a determination that lives in somebody’s head. They will ask how you arrived at your scope, why your risk assessment starts where it starts, and what changed since last year. A short register is the cheapest way to answer all three. Keep one because it is efficient, not because the clause commands it.
What trips people up
Length is not the point. Length often works against you. A two-page register that moved your scope boundary beats a twenty-page PESTLE that moved nothing. Auditors read the second kind and draw the obvious conclusion. You wrote it for them, not for you.
Where the output has to land #
Clause 4.1 is not a standalone deliverable. Three later clauses consume it, and those links are what an auditor traces.
| Clause | What it does with your 4.1 output |
|---|---|
| 4.3 Scope | You have to consider the external and internal issues from 4.1 when you set the ISMS boundary. The scope is the one thing in Clause 4 you have to document. |
| 6.1 Risk | Planning starts from the issues in 4.1 and the requirements in 4.2. A risk assessment that ignores your context is a generic risk assessment. |
| 9.3 Management review | Review has to cover changes in the external and internal issues relevant to the ISMS. This is what makes 4.1 recurring rather than one-time. |
Run the trace backwards on your own documents. Pick a line in your scope statement and find the issue that justifies it. Pick a risk and find the issue it came from. If those threads do not connect, the register is not doing any work.
A method that produces usable issues #
You need no particular technique. ISO 27001 does not mandate SWOT, PESTLE, or anything else. What follows takes a small team about two hours.
Write the intended outcome first #
Goal: one sentence you will test every candidate issue against.
Not the standard’s language. Yours. Two examples. “Keep client health data confidential and available so we can sell to Ontario hospitals.” Or this one. “Prove to US enterprise buyers that our platform will not lose their data.”
What goes wrong: teams start from a template of issue categories and never write the sentence. Then you can rule nothing out. There is no test to rule it out against.
List candidates from both directions #
Goal: raw material, generated fast, judged later.
External prompts:
- Which laws bind you
- Which buyers ask for what
- Which suppliers and cloud providers you depend on
- Who attacks companies like yours
- What is changing in your technology
- Whether climate change bears on any of it
Internal prompts:
- What you sell, and to whom
- How you build and ship
- Where data lives, and under whose control
- Headcount, skills and key-person exposure
- How decisions get made
- Funding and runway
- Anything in flight, such as a migration or an acquisition
What goes wrong: only the external half gets done. Internal issues are where the uncomfortable ones live, including the one person who knows how everything works.
Apply the “so what changes” filter #
Goal: cut the list to the issues that force a decision.
Take each candidate and answer one question. If this is true, what has to be different about our ISMS? If the answer is nothing, strike it. A register of eight issues that each change something is worth more than forty that do not.
What goes wrong: nobody strikes anything, because a longer list feels safer. It reads as padding to an experienced auditor.
Rewrite topics as issues #
Goal: every line states a situation, not a subject area.
“Cloud” is a topic. “Production data sits in a US region while three of our five largest prospects require Canadian residency” is an issue. “Staff turnover” is a topic. “Our only administrator with production access is also our only DevOps hire” is an issue. The second kind tells you what to do. The first kind decorates a page.
What goes wrong: the register gets written in nouns. Nouns survive review because nobody can disagree with them.
Record the date and the next review #
Goal: satisfy 9.3 without a scramble.
Put a date on the register and name the trigger for revisiting it. Annual management review at minimum, plus events: new market, new regulator, new cloud region, acquisition, a breach at a peer. Context that never changes is context nobody looked at.
What goes wrong: someone writes the register once during certification. The team rediscovers it a week before the surveillance audit.
The Canadian external issues that apply to you #
Name the ones that bind you. A register listing every Canadian privacy statute signals that nobody checked which apply.
The one that changed this year. Bill C-8 received Royal Assent on 16 June 2026. It enacts the Critical Cyber Systems Protection Act, covering finance, telecommunications, energy and transportation. Designated operators have to protect their critical cyber systems and report significant incidents. Public Safety Canada says the Act arrives “implemented gradually, with certain provisions coming into force through a phased approach”. Its predecessor, Bill C-26, died before it could pass. That is why older Canadian guidance still names the wrong bill.
Check your register’s age
Work in one of those four sectors? If your external issues register predates June 2026, it is missing a statute. That is the clearest case for treating Clause 4.1 as recurring work. It is also the kind of gap a surveillance audit finds.
The rest of the Canadian list. Use it to pick from, not to copy:
- PIPEDA at the federal level, with separate provincial regimes in Quebec, Alberta and British Columbia.
- Quebec Law 25 if you hold personal information about people in Quebec. It carries its own obligations around transfers outside the province.
- PHIPA if you are a health information custodian in Ontario or an agent acting for one.
- OSFI Guideline B-13, effective 31 July 2022. It applies to every financial institution OSFI regulates, including foreign bank and insurance branches. B-10 covers third-party risk, which makes you an external issue in your bank client’s register.
- Canadian data residency expectations from public sector and health buyers. This is a buyer requirement more often than a legal one, and it belongs in your register either way.
One more, easy to miss. Your certification body is an interested party under 4.2, and the Standards Council of Canada accredits the ones whose certificates travel. Worth a line in the register if certification is why you are reading this.
Answering the climate sentence without theatre #
Read the amendment again. It says determine whether climate change is a relevant issue. It does not say conclude that it is. Either answer passes. Neither passes without reasoning.
For an information security management system the honest link is availability. Data centre regions face wildfire smoke, flooding, grid stress and heat. On-site server rooms cook when building cooling fails on a hot week. If your recovery plan assumes a region stays up, climate is relevant to you whatever your view of the wider subject. The 4.2 note points at the other half: buyers and regulators may bring their own climate requirements.
Two sentences of reasoning and a conclusion will satisfy most auditors. Silence will not, and silence is what pre-2024 registers offer.
How to tell if yours is any good #
Three tests, none of which involve counting pages.
- Did it move the scope? Find one boundary in your Clause 4.3 statement that exists because of an issue you identified. If every boundary is arbitrary, 4.1 did no work.
- Did it move the risk assessment? Find one risk in your register that traces to a context issue rather than to a generic threat list.
- Could you swap the company name? Put a competitor’s name at the top and read it again. If it still reads true, you documented an industry, not an organization.
What good looks like
A register short enough to read in five minutes. Specific enough that an outsider learns something about your company. Dated, and traceable into your scope and your risk assessment. None of that needs a consultant or a template.
Frequently asked questions #
Does ISO 27001 require a documented context of the organization?
No. Clause 4.1 and Clause 4.2 carry no documented information requirement. Clause 4.3 does, because the ISMS scope has to be available as documented information. Most teams still keep a short context register. An auditor has to see evidence that the determination happened, and a register is the cheapest form of it.
What is the difference between Clause 4.1 and Clause 4.2?
Clause 4.1 covers issues, meaning conditions and circumstances that affect your ISMS. Clause 4.2 covers interested parties and their requirements, meaning who cares and what they demand. Customers, regulators, staff, shareholders, your certification body and your cloud providers all count as interested parties. A recession, a migration or a new statute counts as an issue.
Do I need a SWOT or PESTLE analysis for Clause 4.1?
No. ISO 27001 mandates no method. SWOT and PESTLE are both fine as prompts and both go wrong the same way, by generating categories nobody then filters. Use whichever helps you produce specific issues, then cut everything that does not change a decision.
What does the climate change amendment require?
Amendment 1:2024 added one sentence to Clause 4.1: “The organization shall determine whether climate change is a relevant issue.” A note in 4.2 adds that interested parties can have requirements related to climate change. You have to consider the question and reach a conclusion. You do not have to conclude that it is relevant, though for availability and recovery planning it often is.
How often should we review organizational context?
At least once a year, because Clause 9.3 requires management review to consider changes in the external and internal issues relevant to the ISMS. Review it sooner on a trigger. A new market, a new regulator, a change of cloud region or provider, an acquisition, or a significant incident at a peer.
What are typical external issues for a Canadian company?
The common ones are PIPEDA and the provincial regimes in Quebec, Alberta and British Columbia. Add Quebec Law 25, PHIPA for Ontario health custodians, and OSFI B-13 and B-10 for the institutions OSFI regulates. The Critical Cyber Systems Protection Act covers four sectors. Canadian data residency expectations come from public sector and health buyers. List the ones that bind you, not the whole set.
Key takeaways #
- Clause 4.1 asks you to determine relevant external and internal issues. The deciding is the work.
- Clause 4.1 and 4.2 require no document. Only the 4.3 scope needs documenting.
- Keep a short register anyway, because it is the cheapest evidence that the determination happened.
- The output has to land in 4.3 scope, 6.1 risk and 9.3 management review, or it did nothing.
- Write issues, not topics. Every line should force a decision.
- Amendment 1:2024 requires you to determine whether climate change is relevant. Either answer passes with reasoning.
- Canada’s Critical Cyber Systems Protection Act became law on 16 June 2026. Older registers miss it.
- If a competitor’s name fits on your register unchanged, rewrite it.
Get Clause 4 right the first time #
Nank.ai runs ISO 27001 programmes for Canadian companies from Toronto, with a dedicated compliance manager and your data held in Canada. We build the context register with you in a workshop. Then we trace it into your scope and your risk assessment, so the audit trail is already there.
