ISO 27001 Clause 4.2, Understanding the Needs and Expectations of Interested Parties

An interested party is defined by ISO as a ‘person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity'.  Generally, these entities would have been known as 'stakeholders', however ISO settled on 'interested party' as the preferred term, with 'stakeholder' retained as an admitted synonym.  

Simply put, an interested party is any entity that could affect, be affected by, or believe itself affected by your ISMS.  A key point to note here is that some interested parties will rate their own significance more highly than you would; that gap is worth bearing in mind when you evaluate their requirements from a business perspective.

As with organisational context, interested parties can be internal or external.  Internally, this typically includes leadership, employees, and legal and compliance teams.  Externally, the list tends to be longer: customers, suppliers, competitors, partners, regulators, insurers, auditors, and occasionally parties that may not initially come to mind, such as landlords or the media.

Let's examine the ISO requirement.  The instruction provided in the Standard is:

‘The organization shall determine:

a) interested parties that are relevant to the information security management system,
b) the relevant requirements of these interested parties,
c) which of these requirements will be addressed through the information security management system.’

The first two points are common to most management system standards.  The third has been added specifically to management system standards following the introduction of ISO’s Harmonised Structure (HS) in 2021.  At present it appears only in those management system standards published against the HS (i.e., those issued from 2022 onwards) and it is, arguably, the most consequential change in this Clause.  

This addition reflects ISO's view that identifying interested parties' requirements was only ever sufficient up to a point; you also need to determine what you intend to do about them.  In practice, this means you must make a deliberate decision about how each interested party requirement will be addressed by your ISMS.  Not every expectation that a stakeholder holds needs to be, or should be, addressed through the management system, and demonstrating that judgement is now an explicit requirement rather than an implied one.

Based on our experience, the most effective way to tackle this is through a structured workshop involving people from across the business. It is important to bring together a range of perspectives because, as we noted in our Clause 4.1 article, good ideas do not just come from senior management.   Once people understand what an interested party is, the conversation usually starts flowing naturally.

When we facilitate these workshops, we encourage participants to think about every organisation, group or individual the business interacts with and not to worry too much about categorising them perfectly.  There is often some overlap with the factors identified during the Clause 4.1 exercise.  The Information Commissioner's Office (ICO), for example, may appear in both discussions. In our experience, identifying the relevant party is far more important than debating exactly which category it belongs in.

We have also found that the discussion is more productive when it focuses on real-world examples rather than a generic stakeholder list.  Ask people to think about contracts that impose security requirements, regulators that influence how the organisation operates, customers that expect assurance, or internal teams that rely on the ISMS.  Starting with tangible examples like these tends to result in a more meaningful discussion and a much stronger assessment

Once the full range of interested parties has been identified, you will need to evaluate their requirements and expectations.  There is a clear distinction between the two.  Requirements are mandatory, such as legal obligations, regulatory conditions and contractual terms.  Expectations are broader and much less formal, such as a general assumption of good service, ethical conduct or social responsibility.

Let’s consider a customer that purchases a cloud-hosted service from your organisation.  Its expectations might include data confidentiality, high availability and secure backup arrangements.  Its requirements will be more explicit: compliance with relevant regulations, fulfilment of legal obligations and adherence to the terms and conditions documented in the contract or service level agreement (SLA) between the parties.

This distinction matters in practice.  Two customers that look identical on paper, both simply categorised as ‘customer’, may have very different requirements.  A public sector customer, for instance, may bring specific security clearance or data residency requirements that a commercial customer would not.  In cases such as this, it may be useful to treat them as separate interested parties rather than classify them under a generic ‘customer’ category.

Once requirements and expectations have been identified, they should be traceable to a source.  Contract reviews, surveys, direct feedback, regulatory publications and industry benchmarking are all reasonable starting points.  

Once you understand your interested parties’ requirements and expectations, the next step is to decide how, and whether, each one will be addressed through the ISMS, as required by the 2022 addition to Clause 4.2.  In practice, I find it useful to map each relevant requirement or expectation against the applicable clauses and controls, much as controls are mapped to risks faced by the business.  This creates a clear record of the judgement made and helps demonstrate how the ISMS responds to the organisation’s real obligations and priorities.

Returning to our previous example of a cloud service customer, their expectations and requirements may be addressed through the ISMS as follows:

• Data confidentiality (expectation) - Clause 7.5.3 Control of documented information, Control 6.6 Confidentiality or non-disclosure agreements
• High availability (expectation) - Control 8.14 Redundancy of information processing facilities
• Secure backup arrangements (expectation) - Control 8.13 Information backup
• Compliance with relevant regulations (requirement) – Control 5.31 Legal, statutory, regulatory and contractual requirements, Control 5.34 Privacy and protection of personal identifiable information (PII), Control 5.36 Compliance with policies, rules and standards for information security.

These considerations could also be used to inform organisational information security objectives under Clause 6.2, or parameters to be measured as part of the requirements of Clause 9.1 (Monitoring, measurement, analysis and evaluation), such as targets relating to service availability or backup frequency and restoration checks.  These objectives or monitoring requirements may be allocated to appropriate representatives within your organisation to maintain oversight.

‍

There are also links between Clause 4.2 and other elements of the Standard.  Clause 4.3 (Scope of the ISMS) is influenced by both the findings from Clause 4.1 (Context) and the requirements of interested parties identified here.  Clause 6.1 (Actions to address risks and opportunities) reflects the same during risk assessment and treatment plans and the allocation of risk owners.  

Clause 7.4 (Communication) requires you to identify how you will keep interested parties informed of relevant ISMS details.  Clause 9.3 (Management review) now requires top management to consider interested parties from two perspectives: firstly, through the proactive input added in the 2022 version of the Standard, covering changes in the needs and expectations of interested parties that are relevant to the ISMS; and secondly, through the reactive input retained from ISO 27001:2013, covering feedback from interested parties.  This recognises that interested parties’ needs and expectations are not static and should be periodically reviewed.

As noted above, interested parties’ expectations and requirements can change and evolve.  However, it’s important to note that the respective ‘value’ of an interested party, both from your perspective and from theirs, may also change over time.  For example, a customer who places only limited emphasis on the services you provide today may come to rely on your organisation far more heavily after awarding you a major contract.  As such, it is important to revisit these relationships periodically.

This is rarely a task for a single department.  Sales and account management often hold the clearest view of customer expectations, legal and procurement understand contractual and regulatory obligations, and HR and compliance are best placed to speak to internal elements such as employees and unions.  Relying on any one function in isolation risks missing particular interested parties or their requirements entirely.

Understanding interested parties is about more than creating a list of stakeholders and their requirements.  In practice, the most effective assessments involve people from across the business, test assumptions against real contractual, regulatory and operational evidence, and record conscious decisions about which requirements and expectations will be addressed through the ISMS.  Periodically revisiting those decisions helps demonstrate that the ISMS remains aligned with business priorities and with the expectations of those who matter most.