Your ISMS Interested Parties List is probably Boilerplate
I like to dig into why things are done a certain way, especially when I keep seeing the same pattern across different organizations. Over the past few years working in compliance, one pattern kept showing up: an ISMS’s interested parties register that looks complete and passes an audit, but is really just a brainstorm. Customers, employees, regulators, suppliers, and insurers are written down with no real analysis behind them. I'm not the only one who's noticed. I've heard auditors comment on exactly this: a list that technically satisfies Clause 4.2 but reads as boilerplate rather than something the organization actually thought through. It became a concrete problem, not just an observation, when I was working with a client and the works council came up. Should it be on the list or not? The honest answer was: I didn't have a rigorous way to decide. So we built one.
Why the usual approach fails quietly
Clause 4.2 asks you to identify interested parties and their requirements. Most registers nail the first half and skip the second. "Employees" sits on a spreadsheet row with no requirement attached, or a vague one like "expect their data to be protected," which is true of literally every party on the list and therefore tells you nothing. That's the quiet failure. A register with no testable requirement per entry isn't wrong, exactly. It's just decorative. It survives an audit because auditors rarely push hard on this clause, not because it's actually doing the job it's meant to do.
Working backward instead of forward
The fix I landed on is simple to state and slightly uncomfortable to apply: stop brainstorming stakeholders from a blank page, and start from the controls you've actually implemented. For each control in your Annex A implementation, ask one question: does this control, as we've built it, create an obligation to someone outside the ISMS boundary? That flips the usual workflow. Instead of guessing who might care, you're looking at what you're actually doing and asking who that gives a legitimate claim to. It's a harder exercise, and a much more honest one, because it's grounded in what exists rather than what might plausibly matter.
A concrete case: the Dutch works council
Here's where the method actually taught me something. I went through a client's Annex A controls with this question in mind, and a handful of them stood out: logging and log review, behavioral monitoring, DLP, endpoint detection, acceptable use enforcement. Not because they're unusual controls- most ISMS implementations have some version of them- but because of what they capture.
There's a real difference between a control that watches a system and a control that watches a person. Logging server uptime is not the same thing as logging which files an individual employee opened, or flagging that someone's behavior looks anomalous. The moment a control can be used to evaluate an individual's conduct or performance, even as a side effect of its primary purpose, it stops being purely a technical control and becomes something with a legal dimension.
In the Netherlands, that dimension has a name: the works council's consent right under the Wet op de ondernemingsraden, which gives employee representation a formal say over any arrangement that monitors staff presence, behavior, or performance. I'd encourage anyone applying this to verify the exact article against current guidance rather than take my word for the citation, but the mechanism itself is the point. A works council isn't on your interested parties list because "employees matter" in the abstract. It's there because a specific set of controls you've already built creates a specific, testable obligation.
That's a very different kind of entry than "customers, expect data protection."
The test, once a candidate shows up
Once a control surfaces a candidate, here's what I now check before adding them to the register:
Leverage. Can this party impose a requirement on you, legally, contractually, or through regulation, that touches information security?
Blocking power. Could they materially affect your ability to achieve your ISMS objectives, delay a control, or force a policy change?
Exposure. Would ignoring their expectations create legal, financial, or reputational risk?
Standing. Do they have a formal basis for this- a statutory role, contract clause, regulatory mandate- rather than a general interest in what you do?
The requirement test. Can you write down, specifically, what they require? Not "they care about security" but the actual obligation.
That last one is the filter that matters most. If you can't answer it concretely, the entry is probably padding, and a register full of padding is worse than a short one, because it buries the entries that actually carry weight.
What this means for your own register
If you're building or revisiting your ISMS, I'd suggest resisting the urge to start with a stakeholder brainstorm. Start with your control implementation instead, and work outward. Ask, control by control, who this creates an obligation to. You'll end up with a shorter list than the brainstorm produces, but every entry on it will survive the question "why is this here?"
It's a small shift in method, and it's the difference between a register that passes audit and one that actually holds up when someone asks you to defend it.
