ISO 27001 Clause 4.1 - Understanding the Organisation and its Context

In my experience of supporting organisations with ISO 27001 implementation and audit, Clause 4.1 is often treated as a short compliance exercise.  The organisations that gain the greatest value from it take a different approach: they use contextual evaluation to understand what is changing around them, involve people with different perspectives and connect the findings directly to decisions about scope, risk and priorities.

Simply put, organisational context is an understanding of the internal and external factors that could influence your organisation’s ability to achieve its objectives.  These factors should be considered from both a positive and negative perspective (i.e., risks and opportunities).  

Let’s consider the ISO requirement.  Clause 4.1 of the Standard states that:  

‘The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system.  The organization shall determine whether climate change is a relevant issue.’

In February 2024, ISO published climate action amendments across the management system standards.  ISO/IEC 27001:2022/Amd 1:2024 added that second sentence to Clause 4.1.  In effect, ISO has singled out climate change as a potential external issue that organisations must explicitly consider when determining their context.  The requirement itself is deceptively simple but is very important.  It asks two things of you: you need to determine whether climate change is a relevant issue and be able to demonstrate how you reached that conclusion.  Deciding that it is not relevant to your ISMS is a perfectly legitimate outcome, but failing to consider it at all, and being unable to demonstrate that you have considered it, is not.

That last point leads to another consideration: ISO standards usually specify where documented information must be maintained or retained.  Unlike many ISO requirements, Clause 4.1 does not explicitly require documented information to be maintained or retained.  In practice, however, it can be difficult to demonstrate that you have properly evaluated your organisational context without some form of supporting evidence.  Although the Standard does not require it, we strongly recommend documenting your context and the rationale behind your conclusions.

There are several ways to approach an evaluation of organisational context, such as a team workshop, a group discussion or a more formal and structured exercise.  I have seen each approach work, but the most effective evaluations tend to use a structured framework while still allowing participants to explore issues beyond fixed categories.  My usual starting point is PESTLE, which considers the following factors:

• Political
• Economic
• Social
• Technological
• Legal
• Environmental

This is commonly referred to as a PESTLE analysis.  Other variations exist, such as STEEPLE, which adds ethical considerations, or PESTLER, which includes reputational factors.  However, the approach adopted should ultimately reflect your organisation’s needs and preferences.  

You will need to consider both internal and external issues.  In practice, I often see organisations apply PESTLE only to external factors, which can leave important internal developments unexplored.  Applying the framework to both perspectives helps reveal issues such as restructuring, changing roles, skills gaps or new working practices before they create information security risks.

When performing a PESTLE analysis, it is not necessary to categorise issues into rigid or mutually exclusive groups.  For example, changes in government policy that increase employment costs or introduce new regulatory obligations are typically outside your organisation’s control, placing them firmly within the category of external issues.  But how should they be classified?  They could be viewed as political factors because they arise from government policy, economic factors because they affect organisational costs, or even social factors because they influence employment and living standards.

One example I frequently encounter is a change in government policy that increases employment costs or introduces new regulatory obligations.  Although the change is external, the organisational response may include reducing staff, combining responsibilities or engaging contractors.  Those decisions can affect access rights, approval structures, segregation of duties and leaver processes, creating information security implications that may not be obvious when the issue is first identified.

Ultimately, the precise category is less important than ensuring the issue has been identified and appropriately considered.  Not every factor requires extensive analysis and explanation, and some have an obvious connection to information security from the outset.  The increasing adoption of artificial intelligence tools would be one example.  The stability of your cross-border data transfer arrangements would be another, as would the emergence of a threat actor targeting organisations in your sector.  All of these are relevant considerations when evaluating organisational context.

I have also seen context evaluations focus almost entirely on the external environment while overlooking internal changes.  Office politics, organisational restructures, mergers, acquisitions and changes to established working practices can all affect information security.  A restructure, for example, may alter reporting lines, access rights, approval routes and control ownership.  Applying PESTLE internally as well as externally helps ensure that these changes are considered before they undermine the ISMS.

Organisational context is not static or a one-off exercise.  These factors are dynamic and can change quickly, sometimes with significant consequences.  You should therefore maintain effective oversight of your organisation’s internal and external context and adapt your ISMS accordingly.  

For example, during one context workshop, a planned organisational restructure initially appeared to be an operational matter rather than an information security issue.  Discussion revealed that it would change reporting lines, approval responsibilities and privileged access arrangements.  Recording the restructure as a contextual issue enabled the organisation to reassess the related risks and controls before the changes took effect.

Like all ISO 27001 requirements, Clause 4.1 does not sit in isolation.  Clause 4.3 requires you to determine the scope of your ISMS, and directs you to consider the internal and external issues identified under Clause 4.1, alongside the requirements of interested parties identified under Clause 4.2.  The outputs of your context evaluation therefore feed directly into how the boundaries of the ISMS are drawn.  If you do not accurately assess your context and interested parties’ requirements the scope may be too narrow, too broad or misaligned with the risks your organisation actually faces.

Consider the climate change amendment, for example.  Clause 4.2 has its own climate provision, noting that interested parties may have climate-related requirements.  So, the same amendment reaches you from two directions: what you determine about climate change internally under 4.1, and what others expect of you under 4.2.  

Clause 6.1.2 requires you to identify risk owners.  These individuals should be well-placed to monitor changes in the internal and external environment, including the threat landscape, and assess how those changes may affect the risks they’re responsible for.

Clause 8.2 requires information security risk assessments to be performed at planned intervals and whenever significant changes are proposed or occur.  A material change in a contextual factor may constitute a significant change and therefore act as a trigger for a reassessment of risk.  

Finally, Clause 9.3, Management review, requires top management to consider changes in internal and external issues relevant to the ISMS.  As such, the outputs of a robust Clause 4.1 evaluation extend far beyond the initial exercise.  They influence planning, risk management, operational activities, and management review throughout the life cycle of the ISMS.

In my experience, the strongest context evaluations involve people from across the organisation rather than relying solely on management.  Senior leaders provide strategic direction, while employees working closer to day-to-day processes often identify operational changes, emerging technologies, supplier issues or practical weaknesses that would otherwise be missed.

For this reason, you should seek input from a broad range of stakeholders when conducting the initial context evaluation.  Doing so often results in a more complete and accurate understanding of the internal and external environment.

‍

The next crucial step is determining how the identified factors should be evaluated.  What risks might they create?  What opportunities might they present?  The answers to these questions provide important inputs into the risk assessment process and help organisations determine the actions necessary to address identified risks and opportunities.

A useful test is to ask whether the context evaluation would help someone understand why the organisation has defined its ISMS scope, risks and priorities in the way it has.  If that connection is not clear, the exercise probably needs further work.  In my experience, the most valuable evaluations are not necessarily the longest; they are the ones that lead to informed decisions and are revisited when circumstances change.