Understanding the environment our ISMS lives in

In the previous post we introduced the Information Security Management System as an operating system for making security decisions. Before we can implement such a system, however, we need to understand the environment in which the organisation operates.

ISO/IEC 27001:2022, Clause 4.1, states:

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.

While this is literally the very first requirement in the standard, it is often taken at face value. However, developing a management system without understanding the organisation it shall serve is like designing a building without knowing its purpose or its surroundings. The building may well stand, but we might end up equipping a retirement home with a callisthenics park: structurally sound, but useless to every resident. Worse, the site may be prone to earthquakes, floods, landslides or other hazards that the design never accounted for. Then the result is not merely absurd, but dangerous.

Security processes and controls chosen without context fail in the same two ways: they either address needs the organisation does not have, and therefore waste resources, or overlook the conditions that actually threaten it.

Whose analysis is it?

Most security managers and consultants come from a technical background. Determining organisational context, on the other hand, is not a technical exercise. It is part of business analysis, a discipline with its own established methods. This is why the requirement above is easy to overlook. When you have never worked with these methods, the clause reads as a boilerplate formality, not as the basis for everything that follows: the scope of the ISMS, the risk assessment, and ultimately the choice of controls.

However, it is unrealistic to expect CISOs and security consultants to be proficient in both security and business analysis. Instead, we should develop a foundational understanding that makes us aware of the different aspects we need to account for, and enables us to extract the relevant information and draw conclusions useful for our ISMS from business analysis reports.

Often, especially within small and medium businesses (SMBs), such reports are not available, and ideally we should be able to facilitate their development. This is not to say that security managers need to do the business analysis themselves, but rather to guide the rest of management (CEO, CFO, and other functional leaders) in providing the information that can later be consolidated into a report useful for the ISMS.

Both security and business managers thus have a stake in the analysis. The business owns the content (knowledge about the market, finances, and strategy) while the security practitioner owns the process: choosing the methods, guiding the discussions, and deciding when there is sufficient information to continue. This process/content distinction comes from facilitation theory (Schwarz, The Skilled Facilitator ), and establishing organisational context is just one of many places where it maps directly onto security practice.

A map of the methods

If SWOT is the only business analysis method you can name, you are in good company — it is by far the most widely known one. But in our view, it is better understood as a synthesis tool rather than an analytical method. SWOT documents an organisation’s strengths, weaknesses, opportunities and threats, but offers no structure for discovering them.

When thinking about all the issues potentially affecting an organisation it is useful to think in three layers, or environments. This is also how the established business analysis methods are organised:

Note how the layers correspond to the language of Clause 4.1: the macro and micro environments are the external issues; the internal context covers the internal ones.

Back to SWOT; the reason it is the most widely known method is its simplicity. It enables key information from different analyses to be integrated into a single overview: strengths and weaknesses pull directly from the internal context, while opportunities and threats come from the micro and macro environments. Unfortunately, its most attractive property is also its biggest weakness. Because SWOT is so easy to produce, it is often the product of a short brainstorming session alone, lacking the deeper analysis needed to discover the organisation’s actual environment.

A showcase

Detailing all methods is beyond the scope of this blog post. The main goal is to draw the attention of security professionals, and provide them with a starting point from which further research can be done.

We would like, however, to go through one example, showcasing what extracting security-relevant context from business analysis reports looks like. For this purpose we will look at the external environment of a fictional German company developing general-purpose frontier AI models. While ACME Labs GmbH is not a real company, the reports tend to capture the reality of the market and industry. Both reports have been generated using Anthropic’s Claude which is expected to have an error rate of 10-30%:

• PESTLE analysis report
• Porter’s Five Forces report

We are intentionally not showcasing an internal context analysis, as such a report would have to be almost exclusively fictitious. We encourage you to read (or at least skim) through the reports before reading on.

Key external issues

Below is a consolidated list of issues within the external environment which can be extracted from the two reports and we think are relevant for the design and implementation of the ISMS of ACME Labs GmbH.

• Elevated and politically-charged threat environment.
  AI is now a subject of state-company conflict (Pentagon-Anthropic rupture), transatlantic relations are adversarial, the Middle East war is active, and the Russia-Ukraine war is ongoing. A European champion positioned against US and Chinese providers is an attractive target for both state-sponsored IP theft and politically motivated attacks.
• Sovereignty and trust are the core of the market positioning.
  93% of German firms prefer a German AI provider; sovereignty-sensitive buyers show lower price sensitivity. But the Porter’s report is explicit: credibility depends on demonstrable substantiation in infrastructure, data handling, governance, and supply chain.
• Trust / adoption asymmetry.
  Trust in AI sits rather low compared to its adoption and the overall enthusiasm about its capabilities. A trust-positioned brand suffers disproportionately from a single incident.
• Regulatory concurrency is the dominant legal issue.
  AI Act general-purpose (GPAI) obligations with full Commission enforcement from Aug 2026. CRA vulnerability reporting starts Sept 2026, with product liability directive (PLD) in force from Dec 2026. German NIS2UmsuCG is in force since Dec 2025. There are multiple enforcement bodies, overlapping scopes and moving deadlines.
• B2B customers impose security requirements down.
  DORA-regulated financial customers, BaFin’s AI guidance, healthcare and public-sector procurement each impose distinct, auditable obligations on ACME Labs as an ICT third-party provider. Procurement functions are sophisticated and run compliance evaluations as standard.
• Extreme supplier concentration.
  Nvidia near-monopoly on GPUs, one French sovereign cloud partner for training, AWS Frankfurt for inference with high switching costs, concentrated data-licensing and tooling vendors. At the same time there is high energy price volatility with German power 2.5-3× the US rates.
• Talent war creates insider risk.
  US compensation is 3-4× the EU levels and poaching is systemic. People will leave, carrying model know-how, training recipes, and potentially data.
• Pace mismatch and economic pressure.
  Frontier capability and pricing move faster than typical corporate multi-quarter planning cycles. Pricing has collapsed significantly. ACME runs on Series B money with general availability planned for Q3 2026. Security budget will be contested and timeline pressure is real.

Notes for the ISMS

Once we have a good overview of the external environment, we need to analyse how these issues affect the ISMS. For each finding in the reports, we ask ourselves: Does this issue affect what we are trying to protect? Does it affect the scope? Does it reveal a certain threat or limitation? Is there perhaps an opportunity? etc.

Below are some notes and conclusions we derived:

• There is a significant tension between high security expectations (regulatory and trust) and potential budgeting issues as the company is operating under very unfavourable economic conditions.
• To optimise performance we should design the ISMS as a compliance integration layer that accounts for multiple frameworks simultaneously: ISO/IEC 27001 Annex A, AI Act, NIS2, CRA, DORA and GDPR. The Statement of Applicability should be written with customer audits and regulatory concurrency in mind. Evidence collection should be aligned across frameworks.
• Position security as a differentiator and key strategic objective.
  ACME cannot compete with existing US and Chinese models on the same playground. The sovereignty claims and customer trust are the entire moat. While security plays a significant role in these claims, this might not be obvious to management and the board. By positioning information security as a differentiator and a key strategic objective in the business strategy, we will ensure awareness, visibility and better grounds for budgeting.
• Additionally we need to see if regulatory burden can be turned into a paid feature.
  For example: DORA-ready contract packs and audit support for B2B customers.
• Scope must cover the sovereignty claim end-to-end.
  Training infrastructure, inference, offices, data pipeline, and supply chain interfaces — all need to be accounted for. Most notably, the reports mention AWS Frankfurt and AWS European Sovereign Cloud, which causes a tension with the “exclusively EU infrastructure” claim. Get a decision on where inference will be operated, and flag potential issues for management. If ACME is currently operating on AWS, management needs to decide if they will accept the distrust risk, migrate to an exclusively European provider, or adjust the marketing from “exclusively EU” to something like “EU data residency”.
• Insider-risk controls need CEO/CTO sponsorship, not ISMS decree.
  Weight-access restrictions, DLP, offboarding rigour, etc. will clash with research culture, and the talent-war context makes friction costly (people we can’t pay competitively leave over annoyances). We need management to own the trade-off explicitly, or the controls will be bypassed within months.
• Get an explicit risk appetite statement.
  With Series B money and a collapsing pricing environment, we can’t gold-plate everything. Our proposal is to go with near-zero appetite for sovereignty-claim breaches and regulatory non-compliance, but higher tolerance regarding loss of IP and lower-tier risks.
• Agile ISMS processes.
  Most notably, a faster review cadence than the standard annual cycle. The reports explicitly noted that the environment is changing rapidly and recommended event-triggered reviews.

Once we have the notes ready, we can decide whether to research some factors further (like regulatory requirements) or directly approach management for the needed decisions.

What’s next

In this post we argued that determining organisational context is part of business analysis, and that security practitioners need enough fluency in its methods to derive, and where necessary facilitate, the analysis. Assuming such reports exist, we demonstrated how to extract relevant information from them and how to derive decisions critical to the proper design and success of the ISMS.

In the next post we will look deeper into EU cybersecurity law, and why it keeps pointing back to risk management.