Skip to main content
Control Institute
Category: Governance and Roles

Interested Parties

Also known as: Stakeholders, Interested Party, Relevant Interested Parties
Simply put

Interested parties are the people and organizations that can affect, be affected by, or believe themselves to be affected by an organization's decisions or activities. In the context of an information security management system, this typically includes groups such as customers, employees, regulators, suppliers, and owners whose needs and expectations the organization should understand.

Formal definition

Under the widely accepted definition, an interested party is a person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity. Within ISO/IEC 27001, identifying interested parties is addressed in the context-of-the-organization requirements (Clause 4), where the organization determines the relevant interested parties for its ISMS and their applicable requirements. The determination of who qualifies as a relevant interested party, and which of their requirements are addressed, depends on the defined ISMS scope and the organization's context rather than a fixed universal list.

Why it matters

Identifying interested parties is foundational to building an information security management system that reflects the real-world obligations an organization faces. ISO/IEC 27001 places this determination in its context-of-the-organization requirements (Clause 4) because an ISMS that ignores the needs and expectations of customers, regulators, employees, suppliers, and owners risks addressing the wrong risks or overlooking obligations that matter to certification. Understanding who can affect or be affected by the organization's decisions helps ensure the ISMS scope and objectives are grounded in actual stakeholder requirements rather than assumptions.

The requirements of interested parties frequently become the source of security and contractual obligations that flow into the ISMS. Customers may impose data protection expectations, regulators may set legal requirements, and suppliers may introduce dependencies that shape risk. Because these requirements inform the ISMS scope and the controls an organization chooses to apply, failing to identify a relevant interested party early can leave gaps that surface later during audits or operational incidents.

It is worth noting that the term "interested party" carries different meanings in other domains, for example, in contract and procurement law an interested party is a prospective offeror whose economic interests are affected by a contract award, and in estate law it refers to someone with the right to contest a will. Within ISO 27001 the concept is specific to the ISMS and should not be conflated with these unrelated legal definitions.

Who it's relevant to

ISMS Managers and Compliance Leads
Those responsible for establishing and maintaining an ISO 27001 ISMS must identify relevant interested parties under Clause 4 and document their applicable requirements, since this determination shapes the ISMS scope, objectives, and downstream risk decisions.
ISO 27001 Auditors and Certification Bodies
Auditors assess whether an organization has adequately determined its relevant interested parties and their requirements as part of evaluating conformity with the context-of-the-organization requirements, recognizing that the appropriate set of parties depends on the defined ISMS scope.
GRC and Risk Professionals
Because the requirements of interested parties, such as customers, regulators, and suppliers, often become inputs to risk assessment and control selection, GRC teams rely on an accurate identification of these parties to ensure obligations are not overlooked.
Executive Owners and Sponsors
Owners and senior leadership are frequently among the interested parties themselves, and they also depend on a clear understanding of stakeholder expectations to allocate resources and set the direction of the ISMS in line with the organization's context.

Inside Interested Parties

Definition within ISO 27001
In ISO/IEC 27001, interested parties are persons or organizations that can affect, be affected by, or perceive themselves to be affected by the information security management system (ISMS). Identifying them is required under Clause 4.2, which sits within the certifiable ISMS requirements (clauses 4 through 10).
Examples of interested parties
Depending on the organization and the defined scope of the ISMS, interested parties may include customers, employees, regulators, suppliers, shareholders, business partners, and other stakeholders. The specific set varies by organizational context.
Needs and expectations
Clause 4.2 requires an organization to determine not only who the interested parties are but also their relevant requirements, which may include legal, regulatory, contractual, and other obligations pertinent to information security.
Relationship to ISMS scope
The identification of interested parties and their requirements is an input to defining the scope of the ISMS (Clause 4.3) and informs the risk assessment and treatment process, including selection of Annex A reference controls via the Statement of Applicability.

Common questions

Answers to the questions practitioners most commonly ask about Interested Parties.

Are interested parties the same thing as SOC 2 Trust Services Criteria stakeholders?
No. "Interested parties" is a concept specific to the ISO/IEC 27001 ISMS requirements (found in Clause 4), where the organization must determine parties relevant to its information security management system and their relevant requirements. SOC 2 does not use this terminology; it is an AICPA attestation examination organized around the Trust Services Criteria, not around an ISMS clause structure. Do not conflate the two frameworks: identifying interested parties under ISO 27001 does not satisfy any SOC 2 requirement, and vice versa.
Does identifying an interested party mean the organization must meet every requirement that party has?
Not automatically. Clause 4 asks the organization to determine the interested parties relevant to the ISMS and which of their requirements are relevant to information security. The organization then decides, typically informed by its risk assessment and scope, which of those requirements it will address through the ISMS. Whether a given requirement becomes a compliance obligation depends on relevance and scoping decisions rather than being mandatory simply because a party was listed.
How do we go about identifying interested parties for our ISMS?
In most engagements, organizations begin by considering groups that can affect or be affected by information security, which can include customers, employees, regulators, shareholders, suppliers, and partners, though the actual list depends on your context and scope. The relevant point is to capture the parties that matter to your ISMS and record which of their requirements relate to information security. The specific parties and requirements vary by organization, so treat any example list as illustrative rather than prescriptive.
Where should the identification of interested parties be documented?
The ISMS requirements call for determining interested parties and their relevant requirements, but the standard does not prescribe a single mandatory format or document. Many organizations capture this within their ISMS context documentation, alongside the scope and the internal and external issues they have identified. The chosen format and level of detail depend on what your certification body's auditor expects to see and how you have structured your management system.
How does the interested parties analysis connect to defining the ISMS scope?
The requirements to understand the organization and its context, to understand the needs and expectations of interested parties, and to determine the scope of the ISMS are closely linked within Clause 4. In practice, the interested parties and their relevant requirements are typically used as inputs when defining and justifying the ISMS scope. Because the certificate covers only the defined scope of the ISMS, getting the interested parties analysis right helps ensure the scope is appropriate.
How often should we review our list of interested parties and their requirements?
The standard treats the ISMS as something to be maintained and improved over time, so the understanding of interested parties is generally revisited as part of ongoing ISMS activities such as management review or when significant changes occur. There is no universally fixed interval; the appropriate cadence depends on your organization's context and the expectations of your certification body. Reviewing when regulatory, contractual, or business circumstances change is a common practice.

Common misconceptions

Interested parties is a concept unique to SOC 2 and its Trust Services Criteria.
The formal requirement to determine interested parties originates in ISO/IEC 27001 Clause 4.2, part of the ISMS requirements. SOC 2 is an attestation examination performed by a licensed CPA firm under SSAE 18 and is organized around the Trust Services Criteria rather than an ISMS clause structure; it does not impose an equivalent 'interested parties' clause, though stakeholder considerations may still be relevant to scoping.
Every possible stakeholder must be listed as an interested party.
The standard requires determining which interested parties are relevant to the ISMS and which of their requirements are pertinent to information security. In most engagements this is a scoping decision informed by organizational context, so the list depends on the defined ISMS scope rather than being a universal, exhaustive roster.
Identifying interested parties once satisfies the requirement permanently.
Interested parties and their requirements can change over time. Organizations typically revisit this determination as part of ongoing ISMS maintenance, management review, and change management, so it is generally treated as a recurring rather than a one-time activity.

Best practices

Document identified interested parties alongside their relevant information security requirements, keeping the record traceable to Clause 4.2 of ISO/IEC 27001.
Use the identification of interested parties as a deliberate input when defining the ISMS scope under Clause 4.3, so the scope reflects who is affected and their expectations.
Distinguish legal, regulatory, and contractual requirements from broader expectations, and capture how each is addressed within the ISMS.
Review the interested parties list periodically, such as during management review, to account for changes in context, stakeholders, or obligations.
Link interested party requirements to the risk assessment and, where applicable, to the selection and justification of Annex A reference controls in the Statement of Applicability.
Avoid assuming that stakeholder considerations map identically to SOC 2; if pursuing both frameworks, treat any alignment as partial and confirm scope requirements for each separately.