ISO 27001 Interested Parties: The Complete 2026 Guide

ISO 27001 interested parties is the part of clause 4 that nearly every implementation gets half right. You list the customers, the regulators, the employees and the cloud providers, you write down what each of them wants, and you move on to scope. Then the auditor asks a question your register has no column for, and you find out that the 2022 edition added a third requirement to clause 4.2 that most templates never caught up with.

This guide covers what clause 4.2 actually demands of your ISO 27001 interested parties register, who belongs on the list, how it feeds scope, risk and management review, and the findings auditors write most often. If you are sequencing the whole project, our ten-step ISO 27001 implementation plan shows where clause 4.2 sits in the build order.

What Clause 4.2 Actually Asks For

Clause 4.2 of ISO/IEC 27001:2022 asks for three determinations, not one. The organization has to determine the interested parties that are relevant to the information security management system; the relevant requirements of those interested parties; and which of those requirements will be addressed through the ISMS.

Those three determinations are the whole test. A register of ISO 27001 interested parties that answers only the first two is answering the 2013 edition, which stopped being certifiable when the transition window closed on 31 October 2025.

The standard adds a note that these requirements can include legal and regulatory requirements and contractual obligations. That note is the reason so many interested parties registers quietly turn into legal registers — more on why those are two different artifacts below.

Here is the part almost nobody states plainly: clause 4.2 never says “shall be available as documented information.” Compare it with clause 4.3 (scope), 5.2 (policy), 6.1.2 (risk assessment process) or 6.1.3 (Statement of Applicability), all of which do. A register of ISO 27001 interested parties is therefore not on the list of mandatory documents, which you can check against our breakdown of the documents ISO 27001 actually requires.

That does not mean you should skip it. You still have to demonstrate that the determination happened, and a register is the cheapest way to do that. It just means the auditor is testing a decision, not admiring a spreadsheet.

The Third Requirement Most ISO 27001 Interested Parties Registers Miss

Item (c) — which requirements will be addressed through the ISMS — was added in the 2022 edition. It is a small phrase with a large consequence: identifying a requirement is not the same as accepting it.

Under the 2013 edition you listed parties and listed requirements, and the implicit assumption was that everything on the list was now your problem. The 2022 text makes the filter explicit. You are expected to look at each requirement and say, in writing, whether the ISMS addresses it and where — or that it does not, and why.

In practice that means one extra column, with answers that look like this:

• Yes, via a control — “Addressed by A.5.19 and A.5.22, supplier security clauses, SoA row 5.19.”
• Yes, via a process — “Addressed by the incident response procedure; 24-hour customer notification built into the escalation step.”
• Yes, via an objective — “Addressed by ISMS objective 3, patch SLA, measured monthly.”
• No, outside the ISMS — “Customer asks for a SOC 2 Type II report. Legitimate requirement, handled by the assurance roadmap, not through this ISMS.”
• No, declined — “Prospect requested on-site right-to-audit. Declined; countered with certificate plus pen-test summary. Approved by the CISO, March 2026.”

Those last two rows are what make the clause useful rather than bureaucratic. Item (c) is the sentence in the standard that lets you keep a scope finite. Without it, every requirement anyone has ever voiced is nominally inside your ISMS, and the first auditor who reads the register against your ISO 27001 scope statement will find the mismatch.

Who Counts as an Interested Party

An interested party is anyone who can impose a requirement on your information security, or who is materially affected by it. That test rules out a surprising amount of what ends up on these lists. “The general public” is rarely an interested party for a B2B SaaS company; a single enterprise customer with a 40-page security addendum certainly is.

Interested party	Typical requirement	Usually addressed through
Enterprise customers	Contractual security clauses, breach notification windows, right to audit	Supplier contracts, incident procedure, SoA controls
Regulators and supervisory authorities	Statutory breach reporting, data protection duties, sector rules	Legal register (A.5.31), incident response plan
Employees	Clear acceptable-use rules, proportionate monitoring, usable training	Topic-specific policies, awareness programme (A.6.3)
Board and shareholders	No material disruption, a certificate that unblocks sales	ISMS objectives (6.2), management review
Suppliers and cloud providers	Defined responsibilities, least-privilege access, exit terms	A.5.19–A.5.23 supplier and cloud controls
Insurers	Evidence of specified controls before underwriting	Internal audit results, control evidence
Certification body	Conformity evidence, notification of significant change	The ISMS itself; change notification process
Parent company or group	Group security standard, consolidated reporting	Scope interfaces and dependencies (4.3)

Length is not a virtue in a list of ISO 27001 interested parties. A forty-row register is a liability, because every row is something an auditor can ask you to evidence and something you have to review. Most certified SMEs run eight to fifteen rows and can defend all of them.

ISO 27001 Interested Parties vs Clause 4.1 Issues vs the Legal Register

ISO 27001 interested parties, clause 4.1 issues and the A.5.31 legal register overlap enough that teams collapse them into one document, then fail all three. They answer different questions and have different evidence obligations.

	Clause 4.1 issues	Clause 4.2 interested parties	A.5.31 legal register
What it captures	Internal and external issues affecting the ISMS outcome	Who has requirements, what they are, and which the ISMS addresses	Laws, statutes, regulations and contracts, plus your approach to meeting them
Documented information mandatory?	No	No	Yes — the control says identified, documented and kept up to date
Typical owner	Top management with the ISMS manager	ISMS manager	Legal or compliance
Feeds	Scope (4.3), planning (6.1.1)	Scope (4.3), planning (6.1.1), management review (9.3.2)	Risk assessment, SoA justification, compliance evidence
Review trigger	Annual, plus material business change	Annual, plus new contract, regulator or market	On legal or contractual change

The practical rule: a requirement that originates in a law or a signed contract belongs in both the interested parties register and the A.5.31 register, but only the A.5.31 version has to be documented and maintained as a control. Keep one as the source of truth and cross-reference, rather than maintaining the same clause in two places and letting them drift.

Where the Register Feeds the Rest of the ISMS

Your ISO 27001 interested parties determination is not a standalone exercise, and the auditor will follow the thread out of it. Four places it has to show up:

• Clause 4.3, scope. When determining the ISMS boundaries you must consider the 4.1 issues, the 4.2 requirements, and the interfaces and dependencies with other organizations. A requirement you accepted under 4.2(c) that sits outside your stated boundary is a direct contradiction.
• Clause 6.1.1, planning. Risks and opportunities are determined by considering the 4.1 issues and the 4.2 requirements. If a customer’s 24-hour notification commitment never appears in the risk assessment, the planning step did not actually use the register.
• Clause 6.1.3 and the SoA. The “where addressed” answers from item (c) should land on named Annex A controls. That makes your Statement of Applicability easier to justify, because several inclusion reasons stop being “best practice” and become “contractual requirement from interested party X.”
• Clause 9.3.2, management review. The 2022 edition added changes in the needs and expectations of interested parties as a mandatory management review input. A review agenda that still uses a 2013-era template will be missing that item, which is one of the easiest nonconformities an auditor can write. Our guide to the ISO 27001 management review has the full input list.

Building the ISO 27001 Interested Parties Register in Six Steps

Six steps that produce a register you can defend at Stage 2 rather than one you have to explain away:

1. Start from the contracts, not from a brainstorm. Pull the security schedules from your five largest customer agreements and your top suppliers. Real obligations with dates and numbers beat a workshop whiteboard every time.
2. Separate the party from the requirement. One party can have five requirements with five different answers. One row per requirement reads badly in a meeting and perfectly in an audit.
3. Write requirements as testable statements. “Customers expect their data to be secure” is not auditable. “Notify the customer security contact within 24 hours of a confirmed breach, per MSA schedule 3” is.
4. Add the 4.2(c) column and actually fill it. Every row gets a yes-with-a-location or a no-with-a-reason. Blank cells are the single most common finding against this clause.
5. Record the source. Statute name and article, contract and clause number, or policy reference. It turns a three-hour evidence hunt during Stage 2 into a thirty-second lookup.
6. Date it and set the trigger. Annual review into management review, plus event triggers: new market, new regulator, a major new contract, an acquisition, a new class of supplier.

Findings Auditors Write Against ISO 27001 Interested Parties

These are the ISO 27001 interested parties findings raised most often at Stage 2 and surveillance. All six are worth checking for before the auditor arrives:

• No answer to item (c). The register lists parties and requirements and stops. This is a conformity gap against the 2022 text, not a style preference.
• Aspirations recorded as requirements. Nothing in the row is testable, so nothing downstream can use it.
• The register contradicts the scope. Requirements accepted under 4.2(c) that relate to systems or sites the scope statement excludes.
• Legal duties listed here but missing from A.5.31. Or the reverse. Two registers, one set of obligations, no cross-reference.
• The register is dated the week before the audit. Nothing says “built for the certificate” more loudly, and surveillance auditors look for it specifically.
• No interested-parties item in management review minutes. The 9.3.2 input exists; the agenda does not reflect it.

Frequently Asked Questions

Is an interested parties register a mandatory ISO 27001 document?
No. Clause 4.2 does not require documented information, and the register does not appear on the list of mandatory ISO 27001 documents. You will still be asked to evidence the determination, and A.5.31 separately requires the legal, statutory, regulatory and contractual requirements to be identified, documented and kept up to date — so in practice almost everyone writes one.

How many ISO 27001 interested parties should we list?
The standard gives no number. Most certified small and mid-sized organizations run eight to fifteen entries. Judge by whether each party can impose a requirement you would have to act on; if not, it is noise you will have to maintain forever.

What changed in clause 4.2 in the 2022 edition?
Item (c) was added, requiring you to determine which interested party requirements will be addressed through the ISMS. In the same revision, clause 9.3.2 gained changes in the needs and expectations of interested parties as a management review input. The rest of the clause 4 wording is largely unchanged from 2013.

Can we decline an interested party’s requirement?
Yes, and item (c) is precisely the mechanism for it. Record the requirement, record that the ISMS does not address it, give the reason and name who decided. A documented, reasoned exclusion is defensible; a silent omission is a finding.

How often should the register be reviewed?
At least annually, fed into management review. Beyond that, treat it as event-driven: a new regulated market, a major customer contract with new security terms, a new supervisory authority, an acquisition, or a change in your own service model.

Where to Start

If you are writing your ISO 27001 interested parties register from a blank page, start with the contracts and work outward — the clause 4.2 determinations are easier to defend when they are traceable to a signed obligation rather than to an opinion. The authoritative reference for the requirement text is ISO/IEC 27001:2022 on iso.org, which also covers the free climate-change amendment published in 2024.

If you would rather not build the register, the scope statement and the A.5.31 legal register from scratch, our ISO 27001 Toolkit ships 165 templates mapped to ISO 27001:2022 for $99, including the clause 4 context and ISO 27001 interested parties documents with the 4.2(c) column already in place.