Learn how to identify the internal and external issues affecting an ISMS, evaluate relevant interested parties and their requirements, and prepare evidence-based records that support ISO 27001 scope decisions.
You have been asked to help establish an Information Security Management System (ISMS) at MedSure Technologies. Management wants a clear plan, and a prospective customer has asked for independent security assurance. Before you recommend controls or write policies, you need to understand the organisation you are trying to protect.
What does the company actually do? What information does it depend on? Which external developments could affect its security? Who has legitimate expectations of the organisation, and which expectations create requirements that need to be managed?
These questions sit at the heart of ISO/IEC 27001 Clause 4. They may appear administrative, but weak answers can cause serious problems later: an unsuitable ISMS scope, missed regulatory or contractual requirements, misdirected investment, or a certification claim that does not reflect the services customers rely on.
In this article, you will learn how to assess organisational context, identify relevant interested parties, evaluate their requirements and turn the findings into usable GRC records.
Organisational context is the set of internal and external issues relevant to an organisation's purpose and its ability to achieve the intended outcomes of its ISMS.
Internal issues originate within the organisation. Examples include the business model, company structure, resources, security maturity, technology architecture, working arrangements, governance and organisational culture.
External issues arise from the environment in which it operates. Examples include customer expectations, regulatory developments, supplier dependencies, market conditions, cyber threats, changing technology and physical disruptions.
An issue is worth recording when there is a credible connection to the ISMS, not simply because it appears on a generic business-risk checklist. For each issue, ask: What is the evidence? Why does it matter to information security? Who can confirm it? What consequence does it have for the ISMS?
For example, “we use cloud computing” is a description, not yet an analysis. A useful context record might say: “MedSure's patient management service depends on Azure-hosted production and supplier-managed infrastructure; the ISMS must address cloud responsibilities, resilience and provider interfaces.”
Context analysis describes the conditions and requirements within which the ISMS must operate. A security risk assessment then examines particular uncertainty and potential consequences for information security.
For example:
Context should inform risk identification, scope and objectives, but it should not be presented as if it already proves a particular risk severity. A list of organisational issues is not a completed risk register.
A practical internal-context review might examine:
For MedSure, the current known facts include 85 employees, a patient-management SaaS platform, Microsoft Azure and Microsoft 365, a GitHub-based development environment and external support services. Its security function has approximately 2.5 full-time-equivalent resources, and management has set an ambitious certification target.
These facts matter because a management system designed for one small office would not adequately reflect the interfaces, people and systems supporting MedSure Cloud. Equally, you should not assume every subsidiary operation or supplier activity is automatically within the eventual certification scope. That determination requires further analysis.
External context can include:
Do not record every imaginable external event as equally relevant. Use evidence and business impact to justify what is included.
Climate change consideration: ISO/IEC 27001:2022 Amendment 1:2024 requires an organisation to determine whether climate change is a relevant issue. It also recognises that interested parties may have related requirements. The assessment should be proportionate to the organisation and its information-security objectives.
For MedSure, a previous office-access interruption caused by flooding and reliance on connectivity and suppliers warrant review. That does not automatically prove a material climate-related security risk or require a broad environmental management programme. Document the relevance decision and the reasoning behind it.
An interested party is a person or organisation whose needs or expectations are relevant to the ISMS. Common examples include customers, employees, regulators, business owners, suppliers, investors, data subjects and prospective certification bodies.
Not every person or organisation associated with the business is automatically relevant. Your job is to identify which parties matter to the ISMS and what relevant requirements they have.
The important distinction is between a stakeholder, an expectation, and an established requirement. For example, a prospective customer may prefer an ISO 27001 certificate, but an unsigned email does not create the same contractual commitment as an executed agreement.
| Interested party | Relevant need or expectation | Source | Current interpretation | Owner / next step |
|---|---|---|---|---|
| Existing healthcare customers | Secure, available service and agreed assurance | Executed agreements | Contractual obligations vary; verify by contract | Customer Assurance / Legal |
| Northbridge prospect | Certificate or agreed independent assurance | Prospect email | Commercial expectation; not a signed contractual condition | Customer Assurance |
| Individuals whose data is processed | Appropriate handling and protection of personal data | Applicable privacy framework | Legal obligations require DPO assessment | DPO |
| Employees | Secure and workable systems, clear responsibilities | Internal HR and security records | Relevant organisational expectation | HR / IT |
| Board | Managed information security exposure and reliable reporting | Board decisions | Management governance expectation | CEO / Security |
| Cloud and support suppliers | Clear interfaces and responsibilities | Supplier contracts | Verify specific commitments | COO / Procurement |
Do not turn this example into a compliance conclusion. Records must show what has actually been verified, which requirements the ISMS will address and what remains uncertain.
ISO 27001 Clause 4.2 expects an organisation to identify relevant interested parties and their relevant requirements, and determine which requirements will be addressed through the ISMS.
A useful working method is to distinguish:
Suppose Northbridge requests ISO 27001 certification or a mutually agreed independent assurance package before signing. Your immediate job is not to record “ISO certification legally mandatory”. Instead, confirm the source and wording, involve the commercial owner, identify potential assurance options and track any later agreed contractual changes.
Likewise, an organisation processing personal data must assess relevant data-protection obligations, but it should not assume that ISO 27001 certification by itself proves privacy compliance.
For each identified requirement, capture its source, applicability, owner, verification status, planned ISMS response and review trigger.
Context and interested-party analysis directly influence the next work: defining ISMS scope under Clause 4.3, establishing the ISMS under Clause 4.4, identifying risks and setting objectives.
For MedSure, the patient-management service depends on application hosting, data storage, identity services, software delivery, support activities, employees and external providers. Even where certain supplier-operated systems remain outside direct organisational control, their interfaces and dependencies still need consideration.
A poor scope decision might include only the head-office IT department and ignore the production service that customers actually use. Another poor decision would be to claim every subsidiary and supplier is fully covered without identifying what MedSure manages and can substantiate.
Article 3 will address those boundary decisions in detail. For now, your task is to produce sufficiently reliable context information to support a defensible scope.
Begin with business strategy, service descriptions, organisational charts, architecture summaries, contracts, customer requirements and interviews. Record source dates and document owners.
Speak with people who understand how the service actually operates: leadership, product, engineering, operations, HR, privacy, customer assurance and supplier owners. Ask for examples and records rather than relying on general assurances.
Use concise, evidenced statements. Explain why each issue matters to confidentiality, integrity, availability or the effectiveness of the ISMS.
Record who matters, their relevant needs, the basis of each requirement and whether it is confirmed, proposed or still under review.
Consider relevant threats to service continuity, office access, supporting utilities and suppliers. Document the conclusion and assumptions; do not force a predetermined outcome.
Ask the COO, CTO, DPO, Customer Assurance Manager and Head of Information Security to verify the parts they can substantiate. Flag unresolved items rather than silently guessing.
Set review triggers. Changes to a major service, customer contract, subsidiary, supplier, applicable legal requirement or operating location may justify an update. Context analysis is not a once-only exercise.
Copying a generic SWOT analysis into the ISMS: A SWOT may help structure discussion, but the result must connect to the ISMS and explain relevance.
Treating every customer request as binding: Verify whether the request has become an accepted contractual or management commitment.
Equating stakeholders with requirements: Listing “regulator” or “customer” is not enough. Determine the applicable requirements and what the ISMS will address.
Ignoring suppliers because they are outside the organisation: Interfaces, outsourced processes and dependencies can materially affect the ISMS.
Declaring climate change irrelevant solely because services are cloud-hosted: Examine relevant physical and supply-chain dependencies, then document a proportionate conclusion.
Making unsupported legal claims: Escalate interpretation to the appropriate legal or privacy specialist and record uncertainty until confirmed.
Failing to update context: Requirements and dependencies change as the business grows. A stale context register can undermine later risk and scope decisions.
You are the GRC Analyst supporting Sofia Reed, MedSure's Head of Information Security.
The organisation has started its ISMS programme. Management wants a short, evidence-based overview before deciding the ISMS scope. You have been given the MedSure Stage 2 Evidence Pack, containing the organisational chart, system and data-flow summary, selected customer obligations, Northbridge's email and a continuity interview.
Produce two deliverables:
Add a 150–250 word management note identifying the three most important uncertainties that should be resolved before the ISMS scope is approved.
You are not being asked to complete a full scope statement or a security risk assessment at this stage. Do not invent signed contracts, legal findings, certified status or undocumented technical controls.
Expected formats: Two spreadsheet tables and one short management note.
In Defining the ISMS Scope, you will use your context assessment to propose realistic ISMS boundaries, identify dependencies and justify what is included or excluded.
Fictional case material is for education. It is not legal advice, audit certification or a finding about a real organisation.