TL;DR
Clause 4.2 has three parts. Name the interested parties, capture their relevant requirements, and decide which of those requirements your ISMS will address. Most registers do the first two and skip the decision.
- Part three is the useful part. It lets you write down that a requirement sits outside the ISMS, and say why. A register with no decision in it is a contact list.
- Needs and expectations are not all requirements. Requirements come in three kinds. Stated, implied, obligatory. That split does your triage.
- Write requirements, not wishes. “Customers want security” is a wish. “Our three hospital clients require patient data to stay in Canada” is a requirement, because you can trace it to a control.
- Clause 4.2 requires no documented information, the same as 4.1. Keep a short register anyway. It is the cheapest evidence.
- This is where data residency enters an ISMS. Not through 4.1, and not through SOC 2, which has no residency criterion at all.
- Amendment 1:2024 added a note: “Relevant interested parties can have requirements related to climate change.”
Sources: ISO/IEC 27001:2022 · IAF and ISO joint communiqué
What Clause 4.2 asks for #
ISO/IEC 27001 is a copyrighted standard, so this guide paraphrases rather than reproduces it. Buy the text before you build against it.
Clause 4.2 sits under “Context of the organization”, next to Clause 4.1. It asks for three things.
- Who the interested parties are. The parties relevant to your information security management system.
- What their relevant requirements are. Relevant is the operative word. Your bank has many requirements. Few of them touch your ISMS.
- Which of those requirements the ISMS will address. This is a decision, not a list, and it is the part teams skip.
Read part three again. The clause does not tell you to satisfy every requirement you find. It tells you to decide which ones your ISMS takes on. So you can write “covered by the master services agreement, not the ISMS” next to a line. And you can defend it.
What good looks like
A register where some rows say no. If the ISMS takes on every requirement you found, you either run a very unusual company, or you made no decisions.
Needs and expectations are not all requirements #
The clause heading says needs and expectations. The requirement says requirements. The gap between those two words is where the work happens.
Requirements come in three kinds. Stated, implied and obligatory. Sort your raw list that way and the triage happens on its own.
| Kind | What it means | Example |
|---|---|---|
| Obligatory | Law or regulation binds you. No negotiation. | PIPEDA breach reporting. PHIPA duties if you handle Ontario health records. |
| Stated | Written into a contract, a questionnaire answer or a signed agreement. | A customer contract requiring encryption at rest and 24-hour breach notice. |
| Implied | Customary in your market. Nobody wrote it down, and everybody assumes it. | Enterprise buyers expect background checks on staff with production access. |
Obligatory requirements are not optional. They belong in the ISMS. Stated ones belong there in most cases. Implied ones are where judgment lives, and where part three of the clause earns its place.
Write requirements, not wishes #
The most common Clause 4.2 register reads like this. Customers, want security. Employees, want privacy. Regulators, want compliance. That register tells an auditor nothing and tells you less.
A usable line names the party, the obligation and where it came from.
What trips people up
Test every row by asking what control it points at. “Customers want security” points at nothing. Now try this one. “Our three Ontario hospital clients require patient data to stay in Canada, per their data sharing agreements.” That points at data residency, supplier terms and transfer controls. If a row points at no control, it is either not a requirement, or you have not finished writing it.
Group your parties before you list requirements. Six groups cover most companies: customers and prospects, regulators, employees, suppliers and cloud providers, owners and investors, and your certification body. Add sector bodies where they apply.
Who belongs on a Canadian ISMS register #
Name the ones that bind you. A register that lists every Canadian privacy authority signals that nobody checked which apply.
- The Office of the Privacy Commissioner of Canada for PIPEDA, at the federal level.
- The Information and Privacy Commissioner of Ontario if you are a health information custodian under PHIPA, or an agent acting for one.
- The Commission d’accès à l’information if you hold personal information about people in Quebec, under Law 25.
- OSFI if you are a financial institution it regulates, which brings Guidelines B-13 and B-10. If you sell to one, B-10 makes you a third party in their programme, and their requirements land in your register.
- Your certification body, accredited in Canada by the Standards Council of Canada. It has requirements about evidence, audit access and timing that your ISMS has to meet.
- A sector regulator under the Critical Cyber Systems Protection Act if you are a designated operator in finance, telecommunications, energy or transportation. Public Safety Canada says the Act arrives “implemented gradually, with certain provisions coming into force through a phased approach”.
Where data residency enters your ISMS #
Canadian buyers ask where their data sits. Teams then look for the clause that covers residency and find nothing, because no clause names it.
Residency enters here, at 4.2, as a requirement of an interested party. Your hospital client requires it. Your public sector buyer requires it. From there it flows into your Clause 4.3 scope and into the controls you select in your Statement of Applicability.
This is worth knowing when you compare frameworks. SOC 2 has no data residency criterion, so a clean report says nothing about where records sat. ISO 27001 has no residency criterion either. What it has is a clause that makes you write down your customer’s requirement and decide what to do about it. That is the difference, and it runs through Clause 4.2.
Do attackers count as interested parties? #
This question comes up in every workshop, and most guidance dodges it.
The concept is broad. A party that can affect your ISMS, one your ISMS affects, or one that believes itself affected. An attacker affects your ISMS, so the words appear to let them in.
Leave them out. Clause 4.2 asks which of a party’s requirements your ISMS will address. An attacker has no requirements you intend to meet, so part three of the clause has nothing to say about them. They belong in your risk assessment under Clause 6.1, as threat sources. Putting them in 4.2 blurs two clauses and gives an auditor something to ask about.
The climate note #
Amendment 1:2024 added a note to Clause 4.2: “Relevant interested parties can have requirements related to climate change.” The IAF and ISO published it on 23 February 2024, alongside a matching sentence in 4.1.
A note is guidance, not a requirement. It still tells you where to look. Public sector procurement, large enterprise buyers and investors ask about climate and resilience more often each year. If any of yours do, that belongs in your register as a stated requirement like any other.
Where the output has to land #
Clause 4.2 is not a standalone deliverable. The same three clauses that consume your 4.1 output consume this one.
| Clause | What it does with your 4.2 output |
|---|---|
| 4.3 Scope | You have to consider the requirements from 4.2 when you set the ISMS boundary. A customer requirement you accepted and then scoped out is a contradiction an auditor will find. |
| 6.1 Risk | Planning starts from the issues in 4.1 and the requirements in 4.2. Requirements you agreed to address become risks if you cannot meet them. |
| 9.3 Management review | Review has to cover changes in the needs and expectations of interested parties. New client, new regulator, new contract term. |
There is a fourth destination that is easy to miss. Requirements you accept in 4.2 often become controls in your Statement of Applicability. When an auditor asks why a control is in scope, “a named client requires it” is a strong answer.
How to tell if yours is any good #
- Does any row say no? If the ISMS takes on every requirement you found, you skipped part three of the clause.
- Can you name the source of each requirement? A contract, a statute, a questionnaire, a signed agreement. “Industry practice” is not a source.
- Does each row point at a control? If it points at nothing, rewrite it until it does or cut it.
- Would a competitor’s register look different? If not, you documented a market rather than a company.
Frequently asked questions #
Does ISO 27001 require a documented interested parties register?
No. Clause 4.2 carries no documented information requirement, and neither does 4.1. Clause 4.3 does, because the ISMS scope has to be available as documented information. Keep a short register anyway. An auditor has to see evidence that the determination happened, and a register is the cheapest form of it.
What is the difference between Clause 4.1 and Clause 4.2?
Clause 4.1 covers issues, meaning conditions that affect your ISMS. Clause 4.2 covers parties and their requirements, meaning who cares and what they demand. A recession or a cloud migration is an issue. A customer contract term or a statute is a requirement.
Are attackers interested parties under Clause 4.2?
In practice, no. Clause 4.2 asks which of a party’s requirements your ISMS will address, and an attacker has no requirements you intend to meet. Threat actors belong in the Clause 6.1 risk assessment as threat sources. Listing them in 4.2 confuses two clauses.
How many interested parties should we list?
There is no number. Six groups cover most companies: customers and prospects, regulators, employees, suppliers and cloud providers, owners and investors, and your certification body. What matters is that each one carries specific requirements you can trace, not that the list is long.
Where does data residency fit in ISO 27001?
At Clause 4.2, as a requirement of an interested party. No clause in ISO 27001 mandates residency, and SOC 2 has no residency criterion at all. It enters because a customer or regulator requires it, then flows into your scope at 4.3 and into the controls you select in your Statement of Applicability.
How often should we review interested parties?
At least once a year, because Clause 9.3 requires management review to cover changes in the needs and expectations of interested parties. Review it sooner on a trigger. A new client with unusual terms, a new regulator, a new market, or a contract renewal that changes your obligations.
Key takeaways #
- Clause 4.2 has three parts. The third one, deciding which requirements the ISMS addresses, is the one teams skip.
- A good register has rows that say no, with a reason.
- Requirements come in three kinds. Stated, implied, obligatory. Sorting them that way does your triage.
- Every row should name a party, an obligation and a source, and point at a control.
- Clause 4.2 requires no document. Keep a short register as evidence anyway.
- Data residency enters an ISMS here, as a customer or regulator requirement.
- Attackers are threat sources for Clause 6.1, not interested parties for 4.2.
- The output feeds 4.3 scope, 6.1 risk, 9.3 review, and often the Statement of Applicability.
Build the register once, and use it #
Nank.ai runs ISO 27001 programmes for Canadian companies from Toronto, with a dedicated compliance manager and your data held in Canada. We build the interested parties register with you, then trace every accepted requirement into your scope, your risk assessment and your Statement of Applicability.
