---

---

---

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.

There are four main subclasses 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 (sometimes referred to as internal or external issues and internal and external factors) 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 factors and issues that could 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, but I rarely actually do them, preferring my own approach.

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 will align with and support those requirements.

For example, if you overlook a regulatory requirement at this stage, you might miss building a control for it later. You can adjust your scope later if needed (but this must be before certification against that scope).

Senior management is responsible for overseeing and approving the identification of interested parties to ensure all relevant perspectives are addressed.

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

---

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 it later during a recertification.

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 you 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 written down, it doesn’t exist​.

Also, the scope needs to be approved by top management (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.

Scope Elements	Questions to help you evaluate scope
Information Assets	What physical locations process that data?
Physical Locations	What physical locations do the assets sit in and process that data? What offices do staff who process the data work in?
Business Functions	What teams process the data? HR / Finance / IT?
Outsourced Services	What services are outsourced, either in terms of sub-processing, or in terms of managing your assets (like external IT Support)

---

Clause 4.4 – Information Security Management System

Clause 4.4 is a short clause that basically says, “establish, implement, maintain and continually improve an ISMS in accordance with the standard.”

Well, that’s helpful…

Essentially, it tells you to set up the ISMS (i.e., all of clauses 4-10 and applicable controls) and keep it running and improving over time.

There isn’t a specific output from 4.4 like a document; it’s a statement that you need to build the management system.

When you comply with all the other clauses and run the ISMS, you are fulfilling 4.4.

However, auditors might still check that you have an overall ISMS framework in place. For example, they may verify that all required processes exist and that management is committed to maintaining the improvement cycle. Regular management reviews and internal audits are essential to ensure the ongoing effectiveness of the ISMS, as they help evaluate the system’s performance and identify areas for continual improvement.

Clause 4.4 is essentially the bridge from planning into doing: “Go ahead and implement an ISMS that meets all these requirements.”

I might document something that summarises the flow of the ISMS, as illustrated by the following diagram;

---

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.

---

---

FAQs

---

Further Reading

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