ISO 27001 clauses
Before any control, clause 4 asks you to describe the business you are protecting.
Clause 4 of ISO/IEC 27001:2022 is the groundwork. You work out the conditions that shape your security, the interested parties who expect something from it, the boundary of the system, and how the ISMS runs as connected processes. Every later clause builds on these answers, so an error here travels all the way to the certificate.
Back to ISO 27001 services01 · Four questions
Four questions, one per sub-clause
Each answer feeds the next, and all four feed risk assessment in clause 6.
The clause is short, and it is easy to treat it as paperwork. It is better read as a briefing you would give a new security lead on day one: what kind of company this is, who is watching, what is covered and how the parts fit.
- 4.1Understanding the organization and its contextThe internal and external conditions that affect what your ISMS can achieve: market, regulation, technology, culture, size.
- 4.2Needs and expectations of interested partiesWho has a stake in your security, what they require of you, and which of those requirements the ISMS will take on.
- 4.3Determining the scope of the ISMSWhere the system starts and stops, drawn from the first two answers, and written down.
- 4.4Information security management systemThe commitment to set up, run, maintain and improve the ISMS as a set of processes that work together.
A 2024 amendment to the standard asks organisations to consider whether climate change is a relevant issue, and notes that interested parties may have requirements about it. For most software companies the honest answer is a one-line judgement, recorded with the other issues.
02 · Internal and external issues
Issues are conditions, not problems
List what your security has to live with, not what is broken.
An issue in this clause is anything that pushes your security in one direction or another. A fast-growing sales pipeline into banks is an issue. So is a team of twelve engineers with no dedicated security hire. Neither is a defect; both change which risks matter and how much you can spend on them.
External
Outside your control
- Customers in regulated sectors who send security questionnaires
- Indian and foreign data protection law that reaches your data
- Dependence on one cloud provider and a few SaaS tools
- The threat climate for your sector, such as credential theft
- Competitors already holding a certificate
Internal
Inside the company
- Headcount, growth rate and staff turnover
- Remote or hybrid working, and personal devices
- How mature engineering practice is: reviews, tests, deployment
- Budget and how decisions get made
- Knowledge held by one or two people
Six to ten issues on each side is usually enough. Each one should be specific to you; if it would fit any company, it adds nothing.
03 · Parties register
An illustrative context-and-parties register for a SaaS company
Who expects something, what they expect, and whether the ISMS takes it on.
Illustrative: a 60-person company in Bengaluru sells a payroll product to mid-sized employers in India and the Gulf. Its register fits on one page.
| Interested party | What they expect | Taken on by the ISMS? | Where it shows up |
|---|---|---|---|
| Enterprise customers | Contracted security terms, breach notice within an agreed time, a current certificate | Yes | Supplier and incident controls, contract register |
| Employees of customers | Their salary and identity data kept private and accurate | Yes | Classification, access control, privacy controls |
| Data Protection Board of India (the Board) | Reasonable security safeguards and breach intimation under the DPDP Act | Yes | Legal register, incident procedure |
| Cloud provider | Use within its terms; customer-side configuration done by us | Yes, our side only | Cloud services control, shared-responsibility note |
| Investors | No event that damages valuation or a funding round | Partly | Risk appetite, management review |
| Own staff | Clear rules, workable tools, fair monitoring | Yes | Acceptable use, awareness, HR controls |
| Payment partner bank | Its vendor security schedule met each year | Yes | Supplier controls, annual attestation |
The third column matters. The 2022 edition asks you to decide which requirements the ISMS will address, so a party can sit on the list with a requirement you consciously handle elsewhere, for example through finance or legal.
04 · Documenting it lightly
How much of this to write down
Only the scope is required as documented information. The rest needs enough to show the thinking.
The standard expects you to have done the analysis for 4.1 and 4.2; it names the scope as the item that must exist in writing. Our page on mandatory documents covers the full list, so here is only the light pattern that tends to work.
- One context note. A page of issues, internal and external, each with a line on why it matters to security.
- One parties register. The table above, owned by the ISMS lead and reviewed when something changes.
- One scope statement. A short paragraph plus a diagram of boundaries and interfaces.
- One process view. A simple map of how ISMS processes connect: risk, change, incidents, audit, review.
- A review trail. Management review minutes that show changes to issues and parties were looked at.
05 · What an auditor samples
How an auditor tests clause 4
By tracing: from a stated requirement to a control, and from the website to the scope.
- Asks a senior leader to describe the business and its pressures, then compares the answer with your context note.
- Picks one party requirement, such as a customer's breach-notice clause, and follows it into the risk register, the Statement of Applicability and a working procedure.
- Reads your website and a sample contract, and checks the product being sold is inside the scope.
- Looks at interfaces: a shared IT team or a parent company outside the boundary, and how security is handled across that line.
- Checks the register has a review date later than the first draft, and that management review considered changes to it.
06 · Common mistakes
Where clause 4 work goes wrong
Most of these surface at Stage 1, when they are still cheap to fix.
- A scope that leaves out what customers buy. Certifying the head office and the corporate laptops, but not the production platform, gives buyers a certificate that says nothing about the service they use.
- Issues copied from a template. Generic lines such as “cyber threats are increasing” show no analysis and give the risk assessment nothing to work with.
- Parties with no requirements. A list of names without what each one expects cannot be traced into controls.
- A register frozen at Stage 1. A new regulated customer or a new market should change it. If it never changes, the auditor will ask why.
- Interfaces ignored. When a group IT team outside the scope runs your identity provider, that dependency has to be named and managed.
Sources: ISO/IEC 27001:2022 clause numbers and titles (clause 4); ISO/IEC 27001:2022/Amd 1:2024 as announced by ISO; the Digital Personal Data Protection Act, 2023 (named only). Descriptions, the register and examples are Auditify's own and illustrative.
Clause 4, answered
Is an interested parties register mandatory?
The analysis is required; a register is the usual proof of it.
The standard asks you to determine your interested parties and their requirements, but it does not name a register as required documented information. Most organisations keep one anyway because it is the quickest way to show an auditor the work was done.
How often should we revisit the context?
When the business changes, and at each management review.
Treat it as a living input. A new market, a large customer, a merger or a new law should prompt an update straight away. The management review is the routine checkpoint where leadership confirms nothing has shifted.
Can clause 4 be excluded if we are very small?
No. Clauses 4 to 10 apply to every certified ISMS.
Only Annex A controls can be marked not applicable, with a reason. The clauses themselves always apply. A small company can meet clause 4 with a few pages, but it cannot skip it.
Who should own the context and parties work?
The ISMS lead drafts it; leadership confirms it.
The ISMS lead usually writes it after short interviews with sales, legal, engineering and HR. Top management should read and confirm it, because it frames every risk decision that follows.
Start the ISMS from an accurate picture of the business.
An ISO 27001 gap analysis reviews your context, parties and scope against clause 4 before an auditor does.