ISO 27001 Clause 4.2: interested parties and the obligations register

The enterprise questionnaire asks what security commitments you have made to your largest client. Nobody on the operations side can say, because the answer sits in a schedule to a Master Services Agreement signed two years ago. ISO 27001 Clause 4.2 is the clause that drags those commitments into the open.

This guide shows compliance leads and security heads how to build the register auditors expect: who to include, how to mine contracts, which requirements to commit to, who owns each row, and what the audit samples.

What does ISO 27001 Clause 4.2 require?

ISO 27001 Clause 4.2 requires three moves: identify the interested parties with a legitimate stake in your security, establish what each of them actually requires, and decide which of those requirements the ISMS will take on. The third step is a considered selection, not a promise to satisfy everyone.

The first two moves are familiar from any stakeholder exercise. The third is where teams stall, because a list of parties feels like a finished deliverable. Without an explicit decision on each requirement, the ISMS either carries commitments nobody chose or ignores ones a client will test.

A requirement can arrive as statute, as a contract clause or as an unwritten expectation. A clause in a signed MSA binds you. A prospect's hope that you avoid certain AI tooling does not, though it may still carry commercial weight.

Clause 4.2 builds on the context work in Clause 4.1 and turns it into a concrete list of obligations. Each move leaves a different artefact:

• Identify: a list of parties, each with a reason it has a stake in your security.
• Establish: the requirements of each party, from statute to contract clause to softer expectation, with the source recorded.
• Decide: an applicability call per requirement, with a stated reason for any you decline.

Why does an interested parties register matter before your first audit?

A structured register turns scattered security obligations into one current list of who requires what, mapped to the controls that answer it. It surfaces contractual commitments nobody operational has read, replaces tribal folklore with evidence, and lets you close enterprise security questionnaires faster at renewal and due diligence.

Mid-market regulated firms typically carry more obligations than they realise. Data protection law, an FCA or PRA relationship, insurer warranties and security schedules buried in client MSAs all accumulate. Most teams discover the gap when a client audit or renewal questionnaire lands, and the answer then costs weeks rather than minutes.

The register changes what happens at that moment. Instead of searching shared drives, you open one current list and answer from it. Due diligence works the same way, when an investor or acquirer asks what you have promised your customers.

Each answer then carries its own proof. When a renewal questionnaire asks how quickly you notify a client of a breach, the register row gives the committed window, the clause it came from, its owner and the control that meets it. Nobody has to reread the MSA.

Who counts as ISO 27001 interested parties?

ISO 27001 interested parties are those whose requirements or influence genuinely touch the ISMS. Externally that means clients, regulators, key suppliers and sub-processors, insurers and the certification body; internally, the board, engineering, HR and sales. The test is relevance, not completeness for its own sake.

Search from both directions, because each finds parties the other misses. Outward, ask who can question you, audit you or end a contract over your security. These are the usual external candidates:

• Clients and their procurement teams, who turn security schedules into audit rights.
• Regulators: the ICO for personal data, plus the FCA or PRA if you are regulated.
• Key suppliers and sub-processors, whose failures become your failures.
• Insurers, whose warranties can bind you to specific controls.
• The certification body, which sets expectations for how you evidence the ISMS.

Inward, ask whose work the ISMS constrains or enables. The board, engineering, HR and sales all belong. Engineering has to build what the register commits to, and sales is the team promising it in negotiation.

Then group the parties and split a group where needs differ. Enterprise clients write security schedules into contracts, while smaller clients on standard terms rely on UK GDPR and your published commitments. Rank the groups by how much they bind you, so contract-mining starts where the binding requirements are.

Two primary sources show how concrete these expectations become. The NCSC supply chain security guidance points organisations towards oversight of suppliers and baseline security expectations for them. For banks, payment and e-money institutions, Solvency II insurers and other in-scope firms, FCA Policy Statement PS26/2 on third party reporting will require a register of material third party arrangements, submitted to the FCA annually, from 18 March 2027. A regulator with a rule like that belongs on your list, with the requirement attached.

Two pitfalls recur. Teams look only at the obvious two, the regulator and the biggest client, and miss insurers, sub-processors and internal functions. Others name parties but never attach a requirement to them.

A page of stakeholder logos is not an analysis.

How do you mine contracts for binding security requirements?

Start with the largest client MSAs, their security schedules, SLAs and Data Processing Agreements, then the main supplier agreements. Extract every security term into the register as a discrete requirement with its source clause. Under UK GDPR, controller–processor contracts must be written, so these documents are legally binding obligations, not background reading.

The ICO guidance on controller and processor contracts sets out what that contract must do. A written contract is needed whenever a controller uses a processor, it must cover appropriate security measures and the use of sub-processors, and it exists so both parties understand their obligations and liabilities. Your clients wrote those terms to be enforced.

Work through the documents in this order:

1. Rank the contracts. Begin with the top clients by revenue and by security demand, then the suppliers that touch customer data.
2. Read the schedule, SLA and DPA together. Breach notification, encryption, access reviews, audit rights, sub-processors and data location hide across all three.
3. Extract each term as one row. Record the requirement in plain words, the contract and clause it comes from, and the counterparty.
4. Add statute and regulation. UK GDPR and any sector rules sit in the same register beside the contract terms.
5. Flag conflicts. Where two clients ask for different things, note it and decide which sets your baseline.

Most of the time goes on your largest client's MSA, which is often the most demanding document you are subject to.

A security schedule nobody operational has read is a liability with a signature on it.

How do you decide which requirements the ISMS commits to?

Record an applicability decision on every register row: the ISMS either commits to the requirement or declines it, with a stated reason. Statute and contract terms are the hard end; softer expectations are weighed on their commercial weight. Declining a nice-to-have on the record prevents gold-plating and is legitimate.

Two tests keep the call consistent. Anything binding, meaning statute and signed contract terms, is accepted by default, and the work is mapping it to a control. Softer expectations, such as a prospect's preference or a question about AI use, are weighed on commercial weight: how many deals depend on them and what meeting them would cost.

Add three columns to every row:

• Decision: commit or decline.
• Reason: one sentence a stranger could follow, such as "binding under client MSA" or "no contract term; revisit if more clients ask".
• Reviewer and date: who made the call and when.

Declined rows stay in the register. They give you a ready answer when an auditor asks which requirements you chose not to bring in. They also show when to think again: a preference one prospect raised can become a signed term once more clients ask for it, so revisit each decline at the annual pass.

Who should own each row of the register?

One register, federated ownership. Legal holds the statutory and regulatory rows, procurement the supplier terms, and account managers the client commitments, while the ISMS owner consolidates the whole and takes it to management for sign-off. Ownership by function stops the register dying inside one team's silo.

Each owner watches their own source of change. Legal tracks regulation, procurement tracks supplier terms at onboarding and renewal, and account managers track what clients ask for in negotiation. The ISMS owner does not write those rows. They own the consolidation and the quality of the register as a whole.

Owners need a duty as well as a name, so set the rhythm once:

• Annual pass: every row confirmed or retired, dated and signed off by management, not only by IT.
• Trigger events: a major new contract, a supplier change, an incident or a regulatory development re-opens the register.

How does ISO 27001 Clause 4.2 integration work with Annex A, Clause 4.3 and 6.1.2?

Each accepted requirement is mapped to the policy or control that discharges it, which is the traceability auditors test. The accepted set then shapes the scope decision in Clause 4.3 and feeds the risk assessment in Clause 6.1.2. A register without a mapping column is a list, not a management tool.

The register has four downstream outputs:

• Annex A controls and policies: every accepted row names what discharges it, such as the access control policy for a client's access-review clause.
• Clause 4.3 scope: a requirement that applies to a system, site or service pulls that asset inside the boundary you define.
• Clause 6.1.2 risk assessment: failing to meet a binding requirement is a risk to record and rate like any other.
• Clause 7.4 communication: the same list of parties tells you who needs to hear what about the ISMS, when, and through which channel.

The mapping column is where the effort pays back. A client asks which control delivers their breach-notification clause, and you answer from the register in minutes. Reading the column the other way is just as useful: for any control, list the requirements it discharges, and you see which controls carry real commercial weight.

Check for empty mapping cells before every review. An accepted row with no control is the first thing an auditor's contract sample finds.

What evidence and sampling should you expect at a Clause 4.2 audit?

Auditors expect a living register carrying requirements, applicability decisions, owners and control mappings, plus the contracts, insurance schedules and a dated review trail with sign-off from beyond IT. They typically sample one client contract and trace its security clauses through the register to a control; a clause that dead-ends is the classic finding.

Prepare this evidence set:

• The register itself, with requirements, applicability decisions, owners and control mappings.
• A legal, regulatory and contractual obligations list, often the same artefact, cross-referenced to policies.
• The contracts, DPAs and SLAs whose security terms the register reflects.
• The insurance schedule and any warranties the insurer imposes.
• A review trail showing dated changes, participation from beyond IT and management sign-off.

Expect questions like these in the room:

• "Who did you decide has a stake in your ISMS, and how did you find them?"
• "Pick this client. What have you promised them about security, and which control delivers it?"
• "Which identified requirements did you choose not to bring into the ISMS, and why?"
• "Who owns your regulatory watch, and when did the register last change?"

Rehearse the contract-to-control walk before the auditor does. Pick your largest client, choose a security clause, and trace it to a register row, an owner and a control. Review dates and owners get checked too, so a stale row shows up quickly.

Certification bodies typically grade by pattern. No discernible identification of interested parties and their obligations is the absence-of-requirement case and grades major. An out-of-date register, a missing owner or an unmapped requirement grades minor, and minors aggregate to major when the same gap recurs across rows.

How can GRC engineering keep the register current automatically?

Run the register as a dataset keyed to contracts: a new MSA or DPA signature triggers a review task to extract its security terms, regulatory-watch feeds are triaged into owned, dated changes, and the mapping column links to the control library so 'which obligations does this control discharge' becomes a query.

The design means nobody has to remember. A signature is an event in the contract system, so the review task fires on it. Regulatory change arrives as a proposed register edit with an owner and a due date, rather than a standing instruction to keep an eye on it.

None of this needs a dedicated GRC platform. A contract system that records signature events, a register held as a database rather than a spreadsheet tab, and a shared control ID between the register and the control library are enough at this scale.

At 50-person scale, that rhythm replaces the annual scramble and gives enterprise reviewers a register they can see is alive.

Frequently asked questions