4.2 — Needs and expectations of interested parties

Not every stakeholder demand belongs in your ISMS. This requirement is as much about deciding what to leave out as what to include.

In plain language

4.2 requires you to identify who has a stake in your information security — customers, regulators, employees, shareholders, partners — figure out what each of them actually requires of you, and then decide which of those requirements your ISMS will formally take on.

Why this requirement exists

Interested parties rarely agree on priorities. A regulator wants specific controls documented a certain way; a major customer wants a security questionnaire answered on their own terms; investors want risk framed in business language. Without a deliberate process to reconcile these, the ISMS either tries to please everyone at once — becoming unwieldy — or quietly favours whichever stakeholder shouted loudest.

Scenario: a company’s largest customer insists on a specific encryption standard the organization considers excessive for its actual risk level. Without a documented decision on which interested-party requirements the ISMS formally addresses, the team either quietly ignores the customer’s ask (risking the relationship) or implements it inconsistently across the business (creating uneven, hard-to-audit controls). A deliberate 4.2 decision — addressed as a customer-specific control, scoped explicitly — avoids both outcomes.

What the standard expects

The standard expects the organization to determine the interested parties relevant to the ISMS, and the relevant requirements of those interested parties. The 2022 revision added a third, explicit point: the organization must determine which of these requirements will be addressed through the ISMS. That addition matters — it converts a passive listing exercise into an active scoping decision, and it is the direct bridge into how 4.3 draws the ISMS boundary.

In practice

• Build a simple interested-party register: who they are, what they require, and whether the ISMS formally addresses that requirement or explicitly does not.
• Include both formal requirements (laws, regulations, contracts) and informal ones (customer expectations, industry norms) rather than only the legally binding ones.
• Make the “addressed or not” decision explicit and documented — silence on a requirement reads as an oversight, not a deliberate scoping choice.

Evidence the auditor will ask for

• An interested-party register with requirements and an explicit in/out-of-scope decision for each.
• Traceability from a specific interested-party requirement to a control or policy that addresses it.

Common pitfalls

• A list of interested parties with no analysis of what they actually require.
• No explicit decision on which requirements the ISMS addresses — the 2022 addition most commonly missed.

Related requirements

• 4.1 Understanding your context — the complementary half of context: what surrounds you, not just who cares.
• 4.3 ISMS scope — uses the requirements addressed here to help draw the ISMS boundary.
• Parent clause: Clause 4 · Context of the organization

2013 → 2022 mapping