ISO 27001 interested parties register (clause 4.2), with examples
Interested parties are the people and organisations who have a stake in your information security, or who can be affected by it: customers, staff, regulators, insurers, suppliers, investors. The register lists who they are and what they need from you.
It's how your ISMS stays pointed at the people it's actually for.
Why it matters
This is clause 4.2 of ISO/IEC 27001:2022. In summary, you must decide:
- Which interested parties are relevant to the ISMS.
- What their relevant requirements are. These may be written (a contract, a law) or expected (customers expect you to keep their data private).
- Which of those requirements you'll address through the ISMS.
The 2024 amendment notes that interested parties can have requirements related to climate change. Clause 4.3 then asks your scope to take these requirements into account, and clause 9.3 asks management to review changes in them.
Examples
Illustrative entries for a small software company:
| Party | Their requirements | Addressed by the ISMS? |
|---|---|---|
| Customers | Data kept confidential and available; security questionnaires answered; breach notification | Yes |
| Staff | Clear rules; their personal data protected | Yes |
| ICO (regulator) | UK GDPR compliance, including breach reporting | Yes |
| Cloud host | Acceptable use of their service | Yes, through supplier controls |
| Insurer | Minimum controls such as MFA and backups | Yes |
| Investors | Security risks managed; no reputational damage | Yes |
What an auditor looks for
- The register exists and covers the obvious parties: customers, staff, regulators and key suppliers.
- Requirements are specific. "Customers: ISO 27001 certificate, response to security questionnaires within the tender deadline" beats "customers: security".
- A decision on each requirement: whether the ISMS addresses it.
- A link through the ISMS. Legal and contract requirements appear in your legal register and supplier or contract records; customer needs are reflected in objectives.
- Review. Changes are discussed at management review.
Common reasons it fails: no record; generic entries; or requirements that never feed anything else.
Common mistakes, and how to keep it manageable
- Listing every customer by name. Group them ("NHS customers", "commercial customers") unless one has unusual requirements.
- Copying contract terms in full. Summarise the security requirement here and link to the contract record for the detail.
- Leaving out internal parties. Staff and management are interested parties too.
- Never revisiting it. New customers, new laws and new insurers change it.
How to do it in ClearIMS
- Open Interested parties and add each party, or group of parties.
- Record their requirements and whether the ISMS addresses each one.
- Get it approved. A named person approves the records, with an approval record.
- Review it at management review. Changes since the last review count towards the next management review.
Related pages
- Context issues: clause 4.1, the other half of your context.
- Legal register: the legal and regulatory requirements in detail.
- Contract obligations: what customers and suppliers have required in writing.
- ISMS scope: which must take these requirements into account.