Skip to content

Clause 4.2 of ISO/IEC 27001:2022, Understanding the needs and expectations of interested parties

You do not get to decide, on your own, what counts as good enough security.

Clause 4.2 asks three questions and produces one table.

  • Who has a stake? Not everyone. The ones whose interests touch the information you hold.
  • What do they need? Stated and unstated. Both count.
  • Which of it binds you? The filter. This is the part people skip.
Who has a stake, what they require, and which of it binds you A concept map of clause 4.2. At the centre is the interested parties register: a living list of who has a stake in the information the organisation holds. Four peers hang off it, in no particular order. Who they are covers the parties themselves: customers, regulators, employees, suppliers, shareholders, insurers and the public. What they need covers their requirements, stated and unstated, from contract clauses to an unwritten expectation of confidentiality. Which of it binds you is the filter that separates legal, regulatory and contractual obligations from preferences. Where it goes names the downstream clauses: 4.3 scope, 6.1.3 risk treatment and the statement of applicability, and 9.3 management review. The four are peers, not steps, and the map draws no arrows between them. The parties register Clause 4.2. One table: party, need, whether it binds you, and where it is dealt with. Who they are 4.2 a. Customers, regulators, employees, suppliers, shareholders, insurers. What they need 4.2 b. Stated and unstated. A contract clause is stated. Trust usually is not. Which of it binds you 4.2 c. The filter that matters. Legal, regulatory and contractual duties bind. Where it goes 4.2 c. The scope in 4.3, risk treatment and the SoA in 6.1.3, the review at 9.3. Who has a stake, what they require, and which of it binds you A concept map of clause 4.2. At the centre is the interested parties register: a living list of who has a stake in the information the organisation holds. Four peers hang off it, in no particular order. Who they are covers the parties themselves: customers, regulators, employees, suppliers, shareholders, insurers and the public. What they need covers their requirements, stated and unstated, from contract clauses to an unwritten expectation of confidentiality. Which of it binds you is the filter that separates legal, regulatory and contractual obligations from preferences. Where it goes names the downstream clauses: 4.3 scope, 6.1.3 risk treatment and the statement of applicability, and 9.3 management review. The four are peers, not steps, and the map draws no arrows between them. The parties register Clause 4.2. One table: party, need, whether it binds you, and where it is dealt with. Who they are 4.2 a. Customers, regulators, employees, suppliers, shareholders, insurers. What they need 4.2 b. Stated and unstated. A contract clause is stated. Trust usually is not. Which of it binds you 4.2 c. The filter that matters. Legal, regulatory and contractual duties bind. Where it goes 4.2 c. The scope in 4.3, risk treatment and the SoA in 6.1.3, the review at 9.3.

The output is one register. Party, need, whether it binds you, where it is dealt with.

Amendment 1:2024 changes this clause

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

I have confirmed it exists, is free, and applies here. I have not read its text. Take the wording from ISO.

Who they are: external

Party Why they care
Customers Their data is in your systems. Their business depends on your uptime
Regulators and supervisors Statutory duties. They can fine you or stop you trading
Suppliers and subprocessors Your requirements flow down. Their incidents flow up
Insurers Cyber cover is priced on your controls, and claims paid on your evidence
Certification bodies If you are certifying, they are a party in their own right
Law enforcement Lawful access requests, and expectations on evidence handling
The public and the press Reputational exposure, especially for data about non-customers

Who they are: internal

Party Why they care
Employees Their own personal data, and the rules they have to work within daily
The board or owners Loss, reputational damage, the cost of getting it wrong
Internal audit Independent assurance. They will test what you claim
Process and system owners They carry the controls in practice

The internal and external split is a convention, not a requirement

Clause 4.2 just says "interested parties". Splitting the register in two is a practitioner habit, and a useful one: different people find them, and different evidence proves them. Do not present the split as something the standard mandates.

A three-person consultancy holding no personal data has a much shorter list. A short honest list beats a long copied one.

What they need

Stated requirements are written down somewhere.

  • A contract clause or customer security schedule
  • A regulation
  • A tender question

Unstated requirements are real expectations nobody wrote down.

  • A patient expects a clinic to keep records private, whether or not they read the notice
  • An employee expects their manager cannot read their personal messages

Unstated requirements are where reputational damage lives. Ask two questions per party: what would make them angry, and what would make them leave.

Which of it binds you

Bucket Means Do with it
Binding Legal, regulatory or contractual. Not negotiable Into the ISMS. Usually a control, a document, or both
Adopted Not binding, but you chose to meet it Into the ISMS by your own decision. Record that it was a choice
Noted Considered, not being met Stays in the register with a reason

The third bucket is what saves you in an audit. "Why does your ISMS not cover X" is answered by a dated line saying you considered X, and why it is out.

How to do it

  1. Start from 4.1. Many parties are already named in the context picture.
  2. Ask the people who face outward. Sales knows what customers ask. Legal knows the contracts. HR knows what employees expect. Procurement knows what you promised suppliers.
  3. Read the actual contracts. Pull the security schedules from your five largest customer contracts. Dull hour, highest value hour. Most organisations find an obligation they did not know they had.
  4. Classify every line. Binding, adopted or noted. Name who made the call. Date it.
  5. Point each binding requirement somewhere. A control, a policy, a scope clause, a risk. A requirement with no destination has not been addressed.
  6. Review it with the context picture. Same cadence, same meeting.

What good looks like

  • One table, readable in a few minutes.
  • Every row: party, requirement, classification, where it is dealt with.
  • Contractual requirements transcribed from the contracts, with the contract reference in the row.
  • Unstated expectations present, and labelled as unstated.
  • Rejected requirements still listed, with the reason.
  • Dated, owned by a named person, reviewed on a schedule.

Common pitfalls

  • A list of parties with no requirements. That is a third of the clause. The requirements column is the clause.
  • A copied template. Every organisation's parties differ. A generic register is evidence the work was not done.
  • Only stated requirements. If everything came from a document, you skipped the half where reputational risk lives.
  • No classification. Without the three buckets everything looks equally mandatory, and the ISMS ends up bloated or arbitrary.
  • Links to nothing. A register that points at no control or policy gets written once and never used.
  • Confusing this with a project RACI. It is about whose interests the ISMS serves, not who implements it.

Documents this clause should produce

Document For Mandatory? Format
Interested parties register Party, requirement, stated or unstated, classification, destination Yes (7.5.1 b) A spreadsheet, so it sorts and filters
Legal and regulatory requirements register The binding subset. What auditors ask for first Recommended, near-universal in practice Instrument, article, internal owner
Contractual security obligations summary What you promised customers, what you require of suppliers Recommended Short summary per major contract, with the reference
Requirements to controls mapping Shows each binding requirement landing somewhere real Recommended A column in the register, or a small table

Linked documents

Document How it depends on 4.2
Context analysis (4.1) Built and reviewed together. Parties usually surface as context issues first
ISMS scope statement (4.3) Party requirements are an explicit input to scope
Risk assessment (6.1.2) Failing a binding requirement is a risk
Risk treatment plan and SoA (6.1.3) Binding requirements often justify including a control
Objectives (6.2) Objectives should answer the requirements that matter most
Supplier controls (Annex A 5.19 to 5.22) What you owe customers usually flows down to suppliers
Management review (9.3) Changes in parties and requirements are a standing agenda item

Key definitions

Term Meaning here
Interested party Anyone who can affect, be affected by, or perceive themselves affected by what you do
Requirement A need or expectation. Stated, generally implied, or obligatory
Stated Written down somewhere: contract, regulation, questionnaire
Unstated A real expectation nobody wrote down
Binding No choice: legal, regulatory or contractual
Relevant The filter, applied twice. Only relevant parties, and only their relevant requirements

Primary sources

Verify before you rely on it

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

Part of Clause 4, Context of the organisation, which shows how 4.2 depends on the other three. The working files are in the implementation kit.