Written by: Alan Parker, ISO 27001 Consultant
Last Updated: 26/4/26

---

---

Overview of Clause 4: Context of the Organisation

ISO 27001 Clause 4 “Context of the Organisation” is asking you to consider the influences and factors that shape your Information Security Management System (ISMS). Questions like;

• What data are you protecting?
• Who are you protecting it for?
• What systems/business functions process the data?

When we can answer questions like these, we can define the ‘context’ of our organisation’s ISMS.

TLDR: It’s where we define the scope of our security.

I realise why the authors of 27001 chose not to just call it ‘Scope’, because it’s more than that, it’s asking you to look at things that influence and those interested in your security, which both shape your scope and approach.

There are four main sub-clauses within clause 4, each relating to defining the scope and shape of your ISMS.

They are;

---

Clause 4.1 – Understanding the Organisation and its Context

In Clause 4.1, the standard asks you to identify the internal and external issues relevant to your organisation’s purpose and affecting your ability to achieve the ISMS’s intended outcomes.

In simpler terms, what is the context in which your business operates?

“Context” is a strange word to use, but it refers to the internal factors (e.g., your organisational structure, culture, staff size, IT infrastructure, etc.) and external factors (e.g., market conditions, regulatory environment, threat landscape, economic conditions, competitors, technologies, external environment, economic environment, regulatory changes, etc.) that might impact information security.

As part of this process, it is important to identify internal and external issues that could then affect your ISMS.

For a small company, an internal issue might be something like “limited IT staff wearing multiple hats,” and an external issue might be “strict data privacy laws in our industry” or “increasing cybersecurity threats targeting our sector.”

There’s no prescribed method for gathering this information (I use a workbook, which you can access below). Some companies do a SWOT or PESTLE analysis, and others brainstorm in a management meeting. Indeed, I’ve been asked a lot over the years in audits to show my SWOT and PESTLE analysis by auditors, but I rarely actually do them, preferring my own approach. So, you don’t actually have to do a SWOT or PESTLE, but it’s a valid option.

Whichever method you use, consider going a bit deeper and seeking more detail in your analysis to ensure all relevant issues are captured.

The key is to consider what factors influence your organisation’s information security.

Importantly, ISO 27001 does not require a formal documented report for context, but it’s often helpful to write down a summary of these issues (some auditors may interview you to ensure you did consider them if nothing is documented​). This process helps to mitigate risks and supports overall risk management.

Technological advancements, such as artificial intelligence, can significantly impact the external environment and information security, so it’s important to keep these developments in mind.

My ISO 27001 Document Toolkit below contains every document you might need, and tools like my SCOPE WORKBOOK. Grab it below.

---

Clause 4.2 – Understanding the Needs and Expectations of Interested Parties

Clause 4.2 complements the context by focusing on “interested parties”—stakeholders with an interest in your information security. Conducting an interested parties analysis helps ensure all relevant internal and external parties are identified and considered.

Common interested parties include customers, business partners, regulators, shareholders, employees, and other stakeholders. All of these groups of people have an interest in how you handle data, either because it’s theirs or because they need to safeguard it.

Here, you identify who your stakeholders are in relation to the ISMS and what requirements or expectations they have.

Examples: Customers might expect you to protect their data and perhaps have ISO 27001 certification as proof; regulators might require you to comply with specific laws (like GDPR); your executive team might expect the ISMS to reduce security incidents; employees might expect that their data is protected and that security policies are clear.

List the relevant interested parties and their needs or requirements (again, this is not necessarily a required document, but typically, you’d maintain a simple list or table for clarity).

This step ensures your ISMS aligns with and supports those requirements.

For example, if you overlook a regulatory requirement like GDPR at this stage, you might miss building a control for it later.

Senior management is responsible for overseeing and approving the identification of interested parties to ensure all relevant perspectives are addressed. i.e. They need to sign it off as accurate.

Clause 4.2 introduces the stakeholder perspective because your ISMS doesn’t exist in a vacuum; it also gives assurance to these parties.

Examples of Interested Parties

Interested Party	Category (Internal/External)	Interest / Requirements of the ISMS
Board of Directors	Internal	Organisational resilience, risk management, regulatory compliance, and maintaining an exceptional reputation.
Leadership Team	Internal	Integrating security into business functions and ensuring adequate resource allocation
Engineering Team	Internal	Secure development practices, intellectual property (IP) protection, and data security
Human Resources	Internal	Secure handling of employee data and staff security training
Finance and Admin	Internal	Protection of financial records and risk management in financial operations
Employees	Internal	Assurance of data protection and clear expectations for data handling
Supervisory Authorities (e.g. ICO, DPC)	External	Compliance with the General Data Protection Regulation (GDPR) and protection of personal data of EU/UK residents
Customers/Clients	External	Data protection assurance, transparency in handling processes, and contract alignment
Suppliers and Vendors	External	Compliance with security policies and secure data sharing
Partners and Investors	External	Confidence in risk management and IP protection
Certification Bodies	External	Evidence of ISO 27001 compliance and continuous security improvement

How To Conduct an Interested Parties Analysis

I try to keep the whole process of analysing the interested parties simple. We don’t need to overthink it; starting with something like the list above is a good starting point, but you have to do your own thinking.

1. Brainstorm “What” you are protecting – it will lead you to “Whom” you are protecting it for.
   
   Start by gathering your team and asking the first question: “What are we protecting and for whom?” It’s a simple question, but by brainstorming as part of your scope discussions, you’ll come up with things like “employee data!” (employees are interested), “customer data!”, etc. But it doesn’t stop there. Stakeholders are those with a vested interest and are usually easier to identify. Interested parties need you to cast the net a bit wider and think about regulators, shareholders, etc., who will be interested to different levels and different aspects of your security, but interested nonetheless.
   
2. Determine Their Needs.
   
   For each party, you’ll then need to ask yourself: “What do they need?” and “How will our ISMS address their needs?” Capture this and ensure it’s documented.
   
3. Document the Review.
   
   If you are holding this as a meeting, ensure the meeting minutes are documented and available as evidence. This can show the auditor that you really considered the parties and their needs, rather than just taking a generic list from a toolkit like mine, or AI suggestions and pasting them in a document. It shows the entire evaluation process.
   
   In my toolkit, I provide a scope workbook that you can use, and it walks you through the process.
   
   Make sure you are reviewing the interested parties at least once a year (management meetings can be a useful forum), and certainly if there are any major changes to your scope.

---

Clause 4.3 – Determining the Scope of the ISMS

ISO 27001 Clause 4.3 is critical: You must define the scope of your ISMS. The scope sets the boundaries of what your ISMS covers (and, by exclusion, what it doesn’t cover).

Setting a realistic scope is vital for any ISO 27001 implementation, especially in SMEs. Every time I work with a client, I suggest they minimise their scope, at least for the first year, and every time they ignore my advice.

You can always change a scope later during a recertification audit point. It’s good to get it right, but it isn’t written in stone for the years to come.

Key questions include;

• Will your ISMS cover the entire organisation or just one business unit?
• Does it include all locations or maybe just the head office?
• What about certain IT systems – in scope or out of scope?
• Is it customer product- or service-focused, or does it include back-office services?

Clause 4.3 requires you to consider the earlier context (4.1 issues and 4.2 stakeholder requirements) when defining scope. This will help inform your decisions.

You should document the scope statement, typically describing the business areas, locations, assets, and processes included in the ISMS. The scope statement should also clearly reflect the organisation’s activities to ensure all relevant operations and processes are considered.

A clear scope ensures that you focus your efforts where they matter and helps you avoid biting off more than you can chew.

Documenting the scope is mandatory.

ISO 27001 essentially says that if the scope is not documented, it doesn’t exist.

Also, the scope needs to be approved by top management as auditors will check that the defined scope was authorised by leadership, not just decided in isolation by the ISMS implementer.​

When defining scope, consider interfaces and dependencies—if you exclude certain parts, are there interactions with in-scope parts that need to be managed?

For instance, if your HR department is out of scope but provides user onboarding info to IT (in scope), you need to manage that interface to ensure you don’t open a vulnerability in your processes.

A common mistake is making the scope too narrow (missing critical assets or processes, thus not addressing key risks) or too broad (overly complex for a first-time implementation). As I mentioned, it’s a point that needs underlining in my opinion.

To begin with, keep the scope as minimal as possible.

Align scope with your business needs and stakeholder expectations (e.g., if a client is pushing for ISO 27001, they likely care about a specific service or data – ensure that’s in scope). The ISMS scope should also support your organisation’s business goals and strategic objectives, ensuring that information security management is aligned with your overall direction and priorities.

Example of Influences on Scope

---

Clause 4.4 – Information Security Management System

Clause 4.4 is the shortest sub-clause in Clause 4, and on first read it sounds almost circular: “establish, implement, maintain and continually improve an information security management system, including the processes needed and their interactions, in accordance with the requirements of this document.”

In other words, “build the ISMS that the rest of the standard describes.”

That sounds like filler, but it isn’t. Clause 4.4 does three important things:

What does 4.4 actually require you to do?

There’s no single document that satisfies Clause 4.4. Instead, the sub-clause is satisfied by the existence and operation of all the other clauses working together. Auditors typically check 4.4 indirectly by looking at:

• Whether all the required ISMS processes exist (risk assessment, treatment, internal audit, management review, corrective action)
• Whether those processes connect to each other rather than running in isolation
• Whether documented information from one process feeds into another (e.g., risk register entries appearing in management review inputs)
• Whether there’s evidence the ISMS is actually being maintained, not just preserved
• Whether continual improvement is genuine – new corrective actions, updated risks, refined controls – rather than ceremonial

A useful way to think about it

Most people I work with find it helpful to think of Clause 4.4 as the frame of the ISMS – the structure that holds everything else together. Clauses 4.1 to 4.3 tell you what shape that frame should be; Clauses 5 to 10 tell you what goes inside it; 4.4 is what stops the whole thing falling apart.

The diagram below illustrates how the elements of the ISMS interact – the kind of process map auditors expect to see when they ask “show me how your ISMS works”.

What evidence demonstrates Clause 4.4 in practice?

There’s no specific document you produce for 4.4, but you should be able to point to:

• An ISMS framework document or process map showing how the elements of your ISMS connect
• Evidence that the framework is actually being used (recent updates to risk register, management review, internal audit)
• A regular cadence of activity – quarterly risk reviews, annual management reviews, periodic internal audits
• Records that show the ISMS evolving over time, not just being maintained at the level it was at certification

If you can’t produce these, your ISMS may technically exist on paper, but it isn’t functioning as a management system. That’s the kind of finding that gets flagged in surveillance audits, even when none of the individual clauses fails outright.

---

Cloud Services and the Shared Responsibility Model

For most SMEs I work with, a meaningful chunk of your ISMS doesn’t actually live with you. If you run on AWS, Azure, Google Cloud, Microsoft 365 or any other cloud platform, you’ve inherited a set of controls from your provider, and you’re responsible for a different set yourself. ISO 27001 doesn’t address this division particularly well, which is why so many organisations get tangled up in it during Clause 4.

The reality is that scope decisions in 4.3 have to acknowledge what you actually control versus what you rely on someone else to control. There’s no point claiming responsibility for the physical security of the data centre your provider runs – you have no access, no influence, no realistic way to verify it. Equally, you can’t claim it’s not your problem, because if your provider’s data centre fails, your customers will be looking to you, not Amazon.

The practical approach I take with clients is three steps:

The thing nobody tells you is that auditors increasingly want to see this thinking written down. A scope statement that says “the production environment hosted on AWS” without addressing what AWS does and what you do is incomplete. Even a one-page document mapping “shared responsibility for our ISMS” goes a long way.

---

What are the Documentation and Outputs for Clause 4?

The key outputs of Clause 4 are typically;

• Records of approval for the context, interested parties, and scope. These records demonstrate that top management has reviewed and agreed on the organisation’s context and boundaries. Internal audits can provide evidence of compliance by assessing whether these records are accurate and up to date.
• Documentation linking to risk assessments and the Statement of Applicability. It’s important to regularly review and update this documentation as part of effective risk management, ensuring that all identified risks and controls remain relevant and up to date.

---

What Do Auditors Look For in Clause 4 of ISO 27001?

When auditing Clause 4, the auditor will typically check the following:

Understanding of Context

They will evaluate whether you’ve identified relevant internal and external issues.

This might be done by reading your context document or asking questions like, “What factors in your business or environment influence your information security?” Expect to discuss topics such as company size, regulatory pressures, market threats, etc.

Identification of Interested Parties

The auditor may ask who your interested parties are and what your identified requirements are. They want to see that you didn’t overlook a major regulatory requirement or a key security clause in a customer contract.

Scope Document

This is usually a primary focus. The auditor will review your ISMS scope and ensure it’s clearly defined (with no ambiguous wording) and makes sense in the context and with the stakeholders. They’ll verify that it covers the essential parts and aligns with your organisation’s activities.

If your scope is “the IT department”, but your company heavily processes personal data in other departments, expect questions.

The auditor will also seek evidence that the scope was approved by top management (e.g., a signature or meeting record).

Scope Implementation

Auditors often “test” the scope by sampling something outside the scope to see that you are truly excluding it.

For example, if your scope excludes the Finance department, an auditor might speak with someone in Finance to confirm they are not part of the ISMS processes. This ensures you’re not managing something out of scope or, conversely, ignoring something in scope.

Overall ISMS Understanding

Clause 4.4 being general, the auditor might not address it separately; however, by reviewing your whole ISMS, they can confirm that you have established and are maintaining an ISMS.

There’s no specific item for 4.4 except “here’s our ISMS documentation set and how we keep improving it,” as evidenced by the implementation of the other clauses.

---

Common Mistakes in Clause 4

In ten-plus years of helping organisations through Clause 4, the same handful of mistakes come up again and again. None of them is catastrophic on their own, but they all tend to make the rest of the ISMS harder than it needs to be.

---

FAQs

---

Further Reading

Get a copy of ISO 27001:2022 from the ISO store.

---