Skip to content

Clause 4 of ISO/IEC 27001:2022, Context of the organisation

Clause 4 is where the ISMS gets decided, before any control is chosen.

Four subclauses. Four questions.

  • 4.1 Context. What world are we operating in?
  • 4.2 Interested parties. Who else has a say, and what binds us?
  • 4.3 Scope. Where does the system start and stop?
  • 4.4 The ISMS. What is the system made of?
How the four subclauses of clause 4 depend on each other A dependency diagram of clause 4 of ISO/IEC 27001. Two independent inputs sit at the top. Clause 4.1, context, records the external and internal issues that affect information security. Clause 4.2, interested parties, records who has a stake and which of their needs legally bind the organisation. Neither comes before the other; they are usually done in the same workshop. Both feed clause 4.3, the scope, which is highlighted because it is the decision everything downstream inherits and the one named on the certificate. The scope in turn bounds clause 4.4, the information security management system itself: the processes inside the boundary, their owners, and how they interact. Context Clause 4.1. External and internal issues, written down. Interested parties Clause 4.2. Who has a stake, and which needs bind you. Scope Clause 4.3. What is in, what is out, and why. This is the boundary the certificate carries. The ISMS itself Clause 4.4. The processes inside that boundary, their owners, and how they interact. How the four subclauses of clause 4 depend on each other A dependency diagram of clause 4 of ISO/IEC 27001. Two independent inputs sit at the top. Clause 4.1, context, records the external and internal issues that affect information security. Clause 4.2, interested parties, records who has a stake and which of their needs legally bind the organisation. Neither comes before the other; they are usually done in the same workshop. Both feed clause 4.3, the scope, which is highlighted because it is the decision everything downstream inherits and the one named on the certificate. The scope in turn bounds clause 4.4, the information security management system itself: the processes inside the boundary, their owners, and how they interact. Context Clause 4.1. External and internal issues, written down. Interested parties Clause 4.2. Who has a stake, and which needs bind you. Scope Clause 4.3. What is in, what is out, and why. This is the boundary the certificate carries. The ISMS itself Clause 4.4. The processes inside that boundary, their owners, and how they interact.

Get clause 4 wrong and everything downstream inherits the error.

The post that goes with this page: Clause 4 decides your certificate before you pick a single control.

What each one has to produce

Subclause The one artefact
4.1 Context A context picture. One or two pages, dated
4.2 Interested parties A register. Every requirement marked binding, adopted or noted
4.3 Scope A scope statement, signed off, with exclusions justified
4.4 The ISMS A process map. Owners named, interactions drawn

If one of those does not exist, the next clause is built on a guess.

Reading the diagram

  • 4.1 and 4.2 are peers. Neither comes first. Run them in the same workshop.
  • Both feed 4.3. The standard names them as the two explicit inputs to scope.
  • 4.3 is accented because it is the decision you cannot walk back cheaply. It is what the certificate says.
  • 4.3 bounds 4.4. The scope decides which processes are in the ISMS at all.

Clauses 1, 2 and 3, in ninety seconds

Three short clauses sit before the requirements. Two of them matter.

Clause 1, Scope. The scope of the standard, not yours. One thing to take from it: you cannot drop any of clauses 4 to 10 and still claim conformity.

Clause 2, Normative references. One entry. That is the whole clause.

  • The single entry is ISO/IEC 27000, Overview and vocabulary.
  • Normative means it forms part of the requirements. Not a reading list.
  • When 27001 uses a defined term, 27000 decides what it means. Your internal glossary does not.
  • ISO/IEC 27002 is not in clause 2. It is guidance on the Annex A controls. You can implement a control differently, provided you meet the objective. Auditors sometimes treat 27002 as binding. It is not.

Clause 3, Terms and definitions. Points at ISO/IEC 27000, plus the ISO Online Browsing Platform and IEC Electropedia.

Worth knowing because several ordinary words are narrower than they look:

Term People assume It actually means
Information security Protecting IT Confidentiality, integrity, availability of information. Paper counts
Interested party A project stakeholder Anyone affected, or who believes they are. Much wider
Risk Something bad The effect of uncertainty on objectives. Can be positive
Control A technical safeguard Anything that modifies risk. A contract clause is a control
Requirement Mandatory Stated, implied, or obligatory. Only some bind you
Documented information A document Documents and records, plus the medium
Continual Continuous Recurring, with gaps. Not uninterrupted

That last one shows up in written policies constantly, and it is a one-word fix.

The 2022 text is not the current text

ISO/IEC 27001:2022/Amd 1:2024, "Climate action changes", published February 2024, amends clauses 4.1 and 4.2. It is one page and free from ISO: ISO/IEC 27001:2022/Amd 1:2024.

Anyone working from a 2022 PDF alone is working from an incomplete clause 4. Verified against iso.org on 31 July 2026.

Primary sources

Verify before you rely on it

A working interpretation of ISO/IEC 27001:2022, written for practitioners. The standard is the only authoritative source. Check the current text before relying on any wording in an audit or filing.