Clause 4.2 asks two things: who are your interested parties, and what do they specifically require from your ISMS? Both questions need answers. Listing stakeholders without documenting their requirements doesn’t satisfy the clause.
What 4.2 Actually Requires
The standard: “The organization shall determine the interested parties that are relevant to the information security management system, and the requirements of those interested parties that are relevant to information security.”
An interested party is anyone whose requirements could affect your ISMS or who could be affected if it fails. The list is broader than most organizations initially assume.
Who Belongs on the List
Internal parties include leadership, staff, and any internal IT function. Leadership sets direction and allocates resources. Staff handle sensitive data daily. Their requirements shape your policies, training, and tooling.
External parties typically include clients, regulators, cloud service providers, external contractors, and insurers. Each has specific requirements to address.
Easy to miss
Cloud service providers are interested parties. If your organization uses Microsoft 365, AWS, or any platform that holds sensitive data, those providers operate under a shared responsibility model. They are responsible for the security of the platform. You are responsible for how you configure it, who has access, and what data you put in it.
The same applies to external contractors. Anyone with access to your systems or data has security implications. Their requirements, and yours toward them, belong in this document.
An auditor will look for a complete list — not just clients and staff. Regulators are commonly omitted. So are cloud providers. They will also check that requirements are specific: “clients expect confidentiality” is not an answer. What does that mean in practice — encryption, breach notification, signed agreements? And they will check that the requirements listed here have actually influenced the ISMS design. If HIPAA is listed as a requirement but there is no breach notification procedure, the clause is not met.
Common gap: Organisations list internal stakeholders only, omit regulators entirely, and treat cloud providers as outside their responsibility rather than as parties with obligations on both sides.
Which Requirements the ISMS Will Address
The 2022 revision added a third requirement: determine which interested party requirements will be addressed through the ISMS and which will be handled through other means. Not every requirement is an information security matter — and the ISMS should only own what it can actually control.
This feeds directly into Clause 4.3. The requirements you bring into the ISMS become the inputs that shape its scope. For Meridian, every requirement in the register below is addressed through the ISMS.
What the Document Looks Like
Below is an example interested parties register for Meridian Health Partners — a 22-person healthcare practice operating under HIPAA and GDPR.
| Interested Party | Relevant Requirements | How the ISMS Addresses This |
|---|---|---|
| Patients | Confidentiality of health records and PII. Right to access and correct their data. Notification if their data is breached. | Access controls on EHR. Breach notification procedure. Patient rights procedure aligned to HIPAA and GDPR. |
| Leadership / Ownership | Regulatory compliance. Protection of practice reputation. Avoidance of breach-related liability and fines. | ISMS implementation. Management review process. Incident response plan. |
| Staff | Clear security policies. Training on data handling and phishing. Secure tools for clinical and administrative work. | Acceptable use policy. Annual security awareness training. MFA on all systems. |
| Regulators (HIPAA) | Administrative, physical, and technical safeguards for PHI. Breach notification without unreasonable delay, no later than 60 days. Annual risk assessments. | HIPAA-aligned controls. Risk assessment process. Breach notification procedure. |
| Regulators (GDPR) | Lawful basis for processing EU patient data. Data subject rights. Breach notification within 72 hours. Privacy by design. | Data processing register. Privacy notice. 72-hour notification procedure. Data minimisation policy. |
| EHR Cloud Provider | Shared responsibility model — provider secures infrastructure; practice secures configuration, access, and data. | Vendor assessment. MFA enforced. Access review quarterly. Data export and backup process documented. |
| Microsoft (M365) | Shared responsibility model — Microsoft secures the platform; practice secures configuration and user access. | Conditional access policies. MFA enforced for all users. Admin account protection. Regular access review. |
| External IT Contractor | Access to practice systems must be controlled, logged, and revoked on contract end. | Contractor NDA and data handling agreement. Privileged access management. Access removed on contract end. |
| Cyber Liability Insurer | Evidence of reasonable security practices. Incident reporting obligations per policy terms. | ISMS documentation as evidence. Incident response procedure includes insurer notification step. |
Next in this series: Clause 4.3 — Scope. Defining the boundaries of your ISMS — what is in, what is out, and why exclusions must be justified.
