# Context and Interested Parties Analysis: [Organization name]

> Analysis of the internal and external issues and of the interested
> parties that shape an information security management system (ISMS).
> It supports ISO/IEC 27001:2022 + Amd 1:2024 clause 4.1 (issues,
> including the determination of whether climate change is a relevant
> issue), clause 4.2 (interested parties, their requirements and which of
> them the ISMS will address, with the Amd 1 note that parties can have
> climate-related requirements) and clause 4.3 (interfaces and
> dependencies that the scope must take into account). Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it before you write or change the ISMS scope (DOC-ISMS-002,
  `compliance/ms-scope`) and before each risk assessment cycle. Risk
  planning under clause 6.1.1 should start from what this analysis found
  (the 4.1 issues and the 4.2 stakeholder needs), so this document is an
  input to the risk work, not an end in itself.
- Fill section 3 (intended outcomes) first, then run one workshop for
  sections 4 to 9. Bring the people who know customers, contracts, legal
  duties, technology and operations.
- Main pitfall: generic lists ("economy", "competition", "cyber threats")
  that never lead to a decision. Every issue and every requirement must
  point to where it is handled: scope, risk register, objective, control,
  contract or a reasoned "no action".
- The worked examples use Quillmere Health Systems, the library's
  medium-tier fictional organisation. Section 12 shows how the small and
  large settings differ.
- Related templates: `compliance/ms-scope`, `compliance/legal-register`,
  `compliance/risk-methodology`, `compliance/risk-register`,
  `compliance/objectives-register`, `isms/isms-process-map`,
  `isms/supplier-register`, `compliance/management-review`.
-->

## Document control

<!-- Guidance: The context analysis is not a mandatory document in ISO/IEC 27001, but almost every certification body expects to see how you determined issues and requirements. Keeping it controlled, dated and approved is the easiest way to show it. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-003 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ciso], [@coo], [@legal-counsel], [@dpo] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024, clauses 4.1, 4.2, 4.3 |
| Scope reference | DOC-ISMS-002 (ISMS scope) |
| Legal register reference | DOC-ISMS-014 |
| Climate change determination | [Relevant / Not relevant], decided YYYY-MM-DD |
| Workshop date and participants | YYYY-MM-DD, [roles] |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| Chief operating officer | [@coo] | [Approved / Approved with changes] | YYYY-MM-DD |
| Top management representative | [@ceo] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | 2027-01-20 | [@isms-manager] | First analysis for the certification project |
| 1.1 *(Example)* | 2027-07-05 | [@isms-manager] | New hospital framework contract added (IP-03), climate review after colocation heat event |

## Contents

<!-- Guidance: Sections 1 to 3 frame the analysis. Sections 4 to 9 hold the content an auditor samples. Sections 10 to 13 keep it traceable and current. -->

1. Purpose and scope
2. Method
3. Intended outcomes of the ISMS
4. External issues
5. Internal issues
6. Climate change determination
7. Interested parties and their requirements
8. Requirements addressed through the ISMS
9. Interfaces and dependencies
10. Traceability to scope, risks and objectives
11. Monitoring, review and triggers
12. Size tiers
13. Records and evidence
14. References

## 1. Purpose and scope

<!-- Guidance: Say what this analysis covers and how it is used. Questions to answer: which part of the organisation was analysed, and which later documents depend on it? Auditor check: the scope document should visibly use the results of this analysis. -->

This document records how [Organization name] understands its
situation for the purposes of the ISMS. It lists:

- the outside and inside factors that could help or hinder the ISMS in
  delivering what we want from it (clause 4.1);
- our yes-or-no decision on climate change as an issue for the ISMS,
  with the reasoning (clause 4.1 as amended in 2024);
- the interested parties relevant to the ISMS, their relevant
  requirements, and which of those requirements we address through the
  ISMS (clause 4.2);
- the interfaces and dependencies between our activities and activities
  performed by others, as input to the scope (clause 4.3).

The analysis covers [the whole organisation / the business units and
sites listed in DOC-ISMS-002]. Its results feed the ISMS scope
(DOC-ISMS-002), the risk assessment (DOC-ISMS-010 method, DOC-ISMS-016
register), the objectives register (DOC-ISMS-024), the legal, regulatory
and contractual register (DOC-ISMS-014) and the management review inputs
(DOC-ISMS-085).

## 2. Method

<!-- Guidance: Describe how you found the issues and parties so that the next reviewer can repeat it. Questions: who took part, which sources were read, how was each item rated? Pitfall: an analysis written alone by the ISMS manager from a template. Auditor check: evidence that the analysis is grounded in real inputs. -->

The analysis is repeated at each review using the same steps:

1. **Collect inputs.** Strategy and business plan, customer contracts
   and tenders, the legal register, previous risk assessments, incident
   and audit results, supplier register, customer complaints and security
   questionnaires, threat intelligence summaries, and facilities and
   sustainability information.
2. **Run a workshop.** Use the PESTLE headings (political, economic,
   social, technological, legal, environmental) for external issues,
   extended with a separate threat landscape heading. Use governance,
   organisation, people, information, technology, processes and
   contractual relations for internal issues.
3. **Rate each issue.** Effect on the intended outcomes of the ISMS:
   High (could prevent an outcome), Medium (makes an outcome harder),
   Low (minor effect). Mark each issue as a threat, an opportunity or
   both. The rating is a filter for attention, not a risk score; the
   risk scoring uses the 5 x 5 scale in DOC-ISMS-010.
4. **Decide the handling.** For each High or Medium issue, record where
   it is handled: scope decision, risk scenario, objective, control,
   project or "monitor only" with a reason.
5. **Identify parties and requirements.** List each interested party,
   their needs and expectations, which needs are requirements for us
   (legal, contractual, or adopted voluntarily) and whether the ISMS
   addresses them.
6. **Map interfaces and dependencies.** List activities performed by
   others that our in-scope activities depend on, and the information
   that crosses each interface.
7. **Approve and publish.** Approval by top management, communication to
   risk and control owners, entry into the documented information
   register (DOC-ISMS-028).

```mermaid
flowchart TD
  IN["Inputs: strategy, contracts, legal register, incidents, threat intelligence"] --> W["Workshop"]
  W --> I41["External and internal issues (4.1)"]
  W --> CL["Climate change determination (4.1, Amd 1)"]
  W --> P42["Interested parties and requirements (4.2)"]
  P42 --> AD{"Addressed through the ISMS?"}
  AD -->|yes| REQ["Requirements adopted"]
  AD -->|no| OUT["Handled elsewhere, reason recorded"]
  I41 --> IF["Interfaces and dependencies (4.3)"]
  REQ --> IF
  IF --> SC["ISMS scope DOC-ISMS-002"]
  I41 --> RK["Risks and opportunities (6.1)"]
  CL --> RK
  REQ --> RK
  RK --> OB["Objectives DOC-ISMS-024"]
```

## 3. Intended outcomes of the ISMS

<!-- Guidance: Clause 4.1 measures issues against the intended outcomes of the ISMS, so write those outcomes down first. Keep them few and concrete. Auditor check: issues and objectives relate to these outcomes. -->

| ID | Intended outcome | Linked objective |
|---|---|---|
| OUT-01 *(Example)* | Patient scheduling data entrusted by hospital customers stays confidential and accurate | OBJ-ISMS-01, OBJ-ISMS-02 |
| OUT-02 *(Example)* | The managed scheduling service stays available within contracted service levels | OBJ-ISMS-03 |
| OUT-03 *(Example)* | Legal, regulatory and contractual information security and privacy obligations are met | OBJ-ISMS-04 |
| OUT-04 *(Example)* | Customers can rely on independent evidence of our security (certification to ISO/IEC 27001) | OBJ-ISMS-05 |
| [OUT-nn] | [Outcome] | [Objective ID] |

## 4. External issues

<!-- Guidance: List issues outside your control that affect the outcomes in section 3. Use the PESTLE headings plus the threat landscape. Questions: what changed in the market, law, technology and threats in the last year? Pitfall: listing threats as issues without saying how they matter to you. Auditor check: High and Medium issues have a "handled in" entry. -->

| ID | Category | Issue | Threat or opportunity | Effect on outcomes | Rating | Handled in |
|---|---|---|---|---|---|---|
| EXT-01 *(Example)* | Political | Public health systems tighten procurement rules for software suppliers, including security attestations | Both | OUT-03, OUT-04 | High | Objective OBJ-ISMS-05, tender response library (`isms/security-questionnaire-answer-library`) |
| EXT-02 *(Example)* | Economic | Hospital budget pressure delays contract renewals and increases price competition | Threat | OUT-02 (resources) | Medium | Budget plan (DOC-ISMS-031), monitor only |
| EXT-03 *(Example)* | Social | Patients and staff expect clear information about how scheduling data is used | Both | OUT-01, OUT-03 | Medium | Privacy notices, PIMS plan for next year (DOC-ISMS-100) |
| EXT-04 *(Example)* | Technological | Customers move to cloud-hosted electronic health record platforms with API integration | Opportunity | OUT-02 | High | Scope interface IF-04, secure development policy (DOC-ISMS-065) |
| EXT-05 *(Example)* | Technological | Dependence on one colocation provider and one cloud provider for disaster recovery | Threat | OUT-02 | High | Risk RISK-014, ICT readiness plan (DOC-ISMS-047) |
| EXT-06 *(Example)* | Legal | Data protection law in customer jurisdictions (for example GDPR in the EU) and health data rules | Threat | OUT-03 | High | Legal register (DOC-ISMS-014), DPIA process |
| EXT-07 *(Example)* | Legal | Hospital customers fall under cybersecurity laws for essential entities (for example NIS2 in the EU) and pass duties down the supply chain | Threat | OUT-03 | High | Customer security addendum (DOC-ISMS-117), supplier obligations |
| EXT-08 *(Example)* | Environmental | Heat waves and power grid strain in the colocation region | Threat | OUT-02 | Medium | Section 6, risk RISK-021 |
| EXT-09 *(Example)* | Threat landscape | Ransomware groups targeting healthcare suppliers as a route into hospitals | Threat | OUT-01, OUT-02 | High | Risks RISK-003 and RISK-004, threat intelligence procedure (DOC-ISMS-045) |
| EXT-10 *(Example)* | Threat landscape | Phishing and credential theft against support staff with customer system access | Threat | OUT-01 | High | Risk RISK-007, phishing simulation plan (DOC-ISMS-074) |
| EXT-11 *(Example)* | Threat landscape | Exploitation of known vulnerabilities in internet-facing components within days of disclosure | Threat | OUT-01, OUT-02 | High | Vulnerability remediation tracker (DOC-ISMS-072) |
| [EXT-nn] | [Category] | [Issue] | [Threat / Opportunity / Both] | [OUT-nn] | [High / Medium / Low] | [Where handled] |

## 5. Internal issues

<!-- Guidance: List conditions inside the organisation that help or hinder the ISMS. Questions: what about our structure, culture, skills, technology and information makes security easier or harder? Pitfall: only listing weaknesses. Strengths and opportunities count too. Auditor check: internal issues show up in resource and competence planning. -->

| ID | Category | Issue | Threat or opportunity | Effect on outcomes | Rating | Handled in |
|---|---|---|---|---|---|---|
| INT-01 *(Example)* | Governance | Board approved the certification project and a dedicated security budget | Opportunity | OUT-04 | High | Project charter (DOC-ISMS-009) |
| INT-02 *(Example)* | Organisation | Two offices with different IT practices after an earlier acquisition | Threat | OUT-01, OUT-02 | Medium | Secure configuration baseline (DOC-ISMS-060), change plan (DOC-ISMS-025) |
| INT-03 *(Example)* | People | Small security team (ISMS manager plus 3) relative to 320 staff | Threat | All | Medium | Roles and RACI (DOC-ISMS-006), competence matrix (DOC-ISMS-026) |
| INT-04 *(Example)* | People | Strong engineering culture of peer review | Opportunity | OUT-01 | Medium | Secure development policy (DOC-ISMS-065) |
| INT-05 *(Example)* | Information | Health-related personal data processed for hospitals, plus own staff and marketing data as controller | Threat | OUT-01, OUT-03 | High | Asset inventory (DOC-ISMS-012), classification policy |
| INT-06 *(Example)* | Technology | Legacy on-premises scheduling module still used by four customers | Threat | OUT-02 | High | Risk RISK-011, decommission objective OBJ-ISMS-06 |
| INT-07 *(Example)* | Processes | Change management exists for production but not for internal IT | Threat | OUT-02 | Medium | Change enablement (`ops/change-enablement-policy`) |
| INT-08 *(Example)* | Contractual | Standard hospital contracts require breach notice within 24 hours | Threat | OUT-03 | High | Incident response plan (DOC-ISMS-020) |
| [INT-nn] | [Category] | [Issue] | [Threat / Opportunity / Both] | [OUT-nn] | [High / Medium / Low] | [Where handled] |

## 6. Climate change determination

<!-- Guidance: Since Amd 1:2024, ISO/IEC 27001 expects a conscious decision on climate change: is it an issue for this ISMS or not? Either answer can be right. Record the answer either way, with the reasoning, the evidence considered, who decided and when. Pitfall: a one-word "Not relevant" with no reasoning, or a long sustainability essay with no link to information security. Auditor check: a dated, reasoned determination that is revisited at review. -->

### 6.1 How to decide

Answer these questions with facts, not opinions:

1. **Physical effects.** Could heat, flooding, storms, wildfire, drought
   or power and cooling stress affect sites, data centres, network
   routes or key suppliers that support in-scope services?
2. **Dependency effects.** Could climate events disrupt suppliers,
   logistics or staff availability in ways that affect confidentiality,
   integrity or availability of information?
3. **Transition effects.** Could climate-related regulation, customer
   procurement criteria or energy pricing change how we run or source IT
   (for example data centre selection, hardware refresh, cloud regions)?
4. **Interested party requirements.** Do customers, investors, regulators
   or insurers place climate-related requirements on us that touch the
   ISMS (section 7, note on climate requirements)?

If any answer is yes with a plausible effect on the outcomes in section 3,
record climate change as **relevant** and say where the effect is handled.
If all answers are no, record it as **not relevant** with the reasons and
the evidence checked. Both are acceptable outcomes.

### 6.2 Determination record

| Field | Value |
|---|---|
| Determination | Relevant *(Example)* |
| Decided by and date | [@coo], 2027-01-20 *(Example)* |
| Evidence considered | Colocation provider resilience report, cloud provider region information, two cooling incidents at the colocation suite in the last summer, hospital tender criteria *(Example)* |
| Reasoning | Heat events have twice reduced cooling capacity at the colocation suite that hosts the legacy module (EXT-08). Two hospital tenders asked for supplier climate resilience statements (IP-03). The cloud provider regions are assessed by the provider as low physical risk *(Example)* |
| Effects on the ISMS | Availability risk RISK-021, data centre assessment (DOC-ISMS-079), ICT readiness exercise including a cooling failure scenario, tender response text *(Example)* |
| Next review | At the next context review or after a climate-related incident |

### 6.3 Example of a "not relevant" determination

For contrast, a determination of "not relevant" could read *(Example)*:
"All production runs in two cloud regions chosen by the provider for
low physical risk, with automatic failover. Staff work remotely, so no
single office affects service. No customer, regulator or insurer has
placed climate-related requirements on our information security. We
found no plausible effect on the ISMS outcomes. We will revisit this
determination at each annual context review, after any climate-related
incident at a supplier, and when a customer or tender raises the topic."

## 7. Interested parties and their requirements

<!-- Guidance: List parties relevant to the ISMS, their needs and expectations, and which of those are requirements. A requirement can be a law, a contract clause, a certification rule or a voluntary commitment you adopt. Amd 1:2024 adds a note that parties can have climate-related requirements: check for them. Pitfall: listing "regulators" with no named requirement. Auditor check: each requirement adopted is traceable to the legal register, a contract or a control. -->

| ID | Interested party | Internal or external | Needs and expectations | Requirements for us | Climate-related requirement | Owner |
|---|---|---|---|---|---|---|
| IP-01 *(Example)* | Top management and board | Internal | Protected revenue, certification for tenders, no regulatory sanctions | Security budget governance, reporting to the board | None identified | [@ceo] |
| IP-02 *(Example)* | Employees and contractors | Internal | Clear rules, usable tools, privacy of staff data | Employment law duties as controller of staff data | None identified | [@hr-lead] |
| IP-03 *(Example)* | Hospital customers | External | Confidential and available scheduling, prompt breach notice, evidence of security | Contract security schedules, 24-hour breach notice, right to audit, ISO/IEC 27001 certificate within 12 months | Two tenders ask for a supplier climate resilience statement | [@account-director] |
| IP-04 *(Example)* | Patients (data subjects) | External | Their scheduling data is used lawfully and kept safe | Data subject rights handled through hospital controllers | None identified | [@dpo] |
| IP-05 *(Example)* | Data protection authorities | External | Lawful processing, notified breaches | Data protection law in customer jurisdictions (for example GDPR) | None identified | [@dpo] |
| IP-06 *(Example)* | Health sector regulators and national cybersecurity authorities | External | Secure supply chain for essential entities | Obligations passed down by customers under cybersecurity laws (for example NIS2) | None identified | [@legal-counsel] |
| IP-07 *(Example)* | Cloud provider and colocation provider | External | Correct use of services, payment, notice of incidents | Shared responsibility model, acceptable use terms | Colocation provider publishes a climate adaptation plan we rely on | [@it-ops-lead] |
| IP-08 *(Example)* | Cyber insurer | External | Baseline controls in place | Policy conditions: MFA, offline backups, EDR, incident reporting within policy deadline | None identified | [@cfo] |
| IP-09 *(Example)* | Certification body | External | Access to evidence and people during audits | Certification agreement and scheme rules | None identified | [@isms-manager] |
| IP-10 *(Example)* | Investors | External | Risk transparency, resilience | Annual risk reporting | Request for climate risk disclosure in the annual report | [@cfo] |
| [IP-nn] | [Party] | [Internal / External] | [Needs] | [Requirements] | [Climate requirement or "None identified"] | [@owner] |

## 8. Requirements addressed through the ISMS

<!-- Guidance: Since the 2022 edition, clause 4.2 expects you to sort stakeholder requirements into those the ISMS will handle and those it will not. Some requirements belong to other systems (finance, HR, quality). Say which, and why. Auditor check: requirements marked "Yes" show up in the legal register, the SoA or objectives. -->

| Req ID | From party | Requirement | Addressed through the ISMS | How and where | Reason if not or partly |
|---|---|---|---|---|---|
| REQ-01 *(Example)* | IP-03 | Breach notice to customer within 24 hours | Yes | Incident response plan DOC-ISMS-020, A.5.24 to A.5.26 | |
| REQ-02 *(Example)* | IP-03 | ISO/IEC 27001 certificate within 12 months of contract start | Yes | Project charter DOC-ISMS-009, objective OBJ-ISMS-05 | |
| REQ-03 *(Example)* | IP-03 | Right to audit our security controls | Yes | Customer security addendum DOC-ISMS-117 | |
| REQ-04 *(Example)* | IP-05 | Processor duty to notify the hospital controller of a personal data breach without undue delay, and controller duty to notify the authority for our own staff and marketing data (for example GDPR) | Yes | Legal register DOC-ISMS-014, breach assessment (`compliance/personal-data-breach-assessment`) | |
| REQ-05 *(Example)* | IP-06 | Supply chain security duties passed down by essential-entity customers | Yes | Customer security addendum, supplier security agreement DOC-ISMS-068 | |
| REQ-06 *(Example)* | IP-08 | Insurer baseline controls (MFA, EDR, offline backups, incident reporting) | Yes | SoA DOC-ISMS-011 (A.8.5 secure authentication, A.8.7 malware protection, A.8.13 backup, A.5.24 incident management planning) | |
| REQ-07 *(Example)* | IP-03 | Supplier climate resilience statement in tenders | Partly | Availability aspects in RISK-021 and the ICT readiness plan | The emissions part of the statement belongs to the sustainability function |
| REQ-08 *(Example)* | IP-10 | Climate risk disclosure in the annual report | No | | Handled by finance and sustainability reporting; the ISMS supplies availability risk data on request |
| REQ-09 *(Example)* | IP-02 | Employment law duties for staff records | Partly | Access control and retention of HR records (A.5.15, A.5.33) | Wider employment duties are an HR process |
| [REQ-nn] | [IP-nn] | [Requirement] | [Yes / Partly / No] | [Where] | [Reason] |

Requirements marked "Yes" or "Partly" are entered in the legal,
regulatory and contractual register (DOC-ISMS-014) with their source,
owner and review date. Contractual security clauses are tracked per
customer there, not in this document.

## 9. Interfaces and dependencies

<!-- Guidance: Under clause 4.3 a scope is only credible if it shows where your work connects to, or relies on, work done by someone else, including other parts of your own organisation. List them here so the scope document can decide what is in and out. Pitfall: excluding a supplier-run activity without saying how the interface is controlled. Auditor check: every out-of-scope dependency has a control at the interface. -->

| IF ID | Activity performed by others | Performed by | Our in-scope activity that depends on it | Information crossing the interface | In or out of scope | Control at the interface |
|---|---|---|---|---|---|---|
| IF-01 *(Example)* | Cloud infrastructure for production and disaster recovery | Public cloud provider | Managed scheduling service | Customer and patient scheduling data (encrypted) | Out (supplier) | A.5.23 cloud services, supplier register DOC-ISMS-066, cloud services policy DOC-ISMS-044 |
| IF-02 *(Example)* | Colocation facility, power and cooling | Colocation provider | Legacy on-premises module hosting | Customer data on our own servers | Out (supplier); our racks in scope | Data centre assessment DOC-ISMS-079, A.7 physical controls for our cage |
| IF-03 *(Example)* | Payroll and HR platform | SaaS provider | HR records management | Staff personal data | Out (supplier) | Supplier assessment DOC-ISMS-067 |
| IF-04 *(Example)* | Electronic health record platforms | Hospital customers and their vendors | API integration of appointments | Appointment data via authenticated APIs | Out (customer) | Interface agreement, API security standard in DOC-ISMS-065 |
| IF-05 *(Example)* | Out-of-hours monitoring | Managed security service provider | Security monitoring | Security logs and alerts | Out (supplier); our response in scope | Supplier security agreement DOC-ISMS-068, monitoring procedure DOC-ISMS-064 |
| IF-06 *(Example)* | Finance and accounts payable | Internal finance team (outside the ISMS scope) | Supplier payments | Supplier and contract data | Out (other part of organisation) | Internal service agreement, access via named accounts |
| [IF-nn] | [Activity] | [Who] | [Our activity] | [Information] | [In / Out] | [Control] |

```mermaid
flowchart LR
  subgraph IN["In scope: Quillmere Health Systems (Example)"]
    SVC["Managed scheduling service"]
    DEV["Software development"]
    SUP["Customer support"]
    MON["Security monitoring and response"]
    HR["HR records management"]
  end
  CLOUD["Public cloud provider"] -->|"IF-01 hosting"| SVC
  COLO["Colocation provider"] -->|"IF-02 power and cooling"| SVC
  EHR["Hospital EHR platforms"] <-->|"IF-04 API"| SVC
  MSSP["Monitoring provider"] -->|"IF-05 alerts"| MON
  HRP["HR SaaS"] -->|"IF-03 staff data"| HR
```

The diagram shows the dependencies of the in-scope activities from the
table above (IF-02 supports the legacy module, which is part of the
managed scheduling service); IF-06 is omitted because it supports
payments, not an in-scope service.

## 10. Traceability to scope, risks and objectives

<!-- Guidance: Show the chain from context to decisions in one place. Auditors often pick one issue and follow it. Make sure each High item can be followed to a concrete decision. -->

| Source item | Scope decision (DOC-ISMS-002) | Risk (DOC-ISMS-016) | Objective (DOC-ISMS-024) | Control or plan |
|---|---|---|---|---|
| EXT-05 *(Example)* | DR region inside scope | RISK-014 single provider dependency | OBJ-ISMS-03 availability | DOC-ISMS-047 ICT readiness plan |
| EXT-08 and climate determination *(Example)* | Colocation cage in scope | RISK-021 cooling failure | OBJ-ISMS-03 | DOC-ISMS-079 assessment |
| EXT-09 *(Example)* | Whole service in scope | RISK-003 ransomware, RISK-004 supplier compromise | OBJ-ISMS-02 integrity | DOC-ISMS-061 backup policy, DOC-ISMS-064 monitoring |
| INT-06 *(Example)* | Legacy module in scope until decommission | RISK-011 unsupported software | OBJ-ISMS-06 decommission by Q4 | Change plan DOC-ISMS-025 |
| REQ-01 *(Example)* | Support team in scope | RISK-009 late breach notice | OBJ-ISMS-04 | DOC-ISMS-020 incident response plan |
| [ID] | [Decision] | [Risk ID] | [Objective ID] | [Control or plan] |

## 11. Monitoring, review and triggers

<!-- Guidance: Management review (clause 9.3.2) should hear what has shifted since last time, both in the business environment and in what stakeholders want. Plan how you notice those changes between reviews. Auditor check: the last management review minutes mention this analysis. -->

Review cadence: the ISMS manager reviews this analysis at least once a
year, before the risk assessment cycle and before management review.
Owners of interested party rows confirm their rows at the same time.

Review earlier when one of these triggers occurs:

| Trigger | Example | Action |
|---|---|---|
| New or changed law or regulation | A customer jurisdiction adopts a new cybersecurity law | Update EXT and REQ rows, legal register |
| New major customer, market or tender requirement | First customer in a new region | Update IP-03 and REQ rows |
| Change to scope, sites or services | Colocation exit, new office | Update interfaces, then the scope (DOC-ISMS-002) |
| Merger, acquisition or reorganisation | Acquisition of a smaller software company | Full re-run of sections 4 to 9 |
| Major incident or near miss | Ransomware at a key supplier | Update threat landscape, risks |
| Climate-related event affecting a site or supplier | Cooling failure during a heat wave | Revisit section 6 |
| Audit finding or management review decision | Finding that interfaces are not documented | Correct and record |
| New supplier for an in-scope activity | New monitoring provider | Add interface row |

Changes are recorded in the revision history and reported to the next
management review (`compliance/management-review`).

## 12. Size tiers

<!-- Guidance: The analysis scales with the organisation. A small company can do it in a two-hour workshop on one page; a group needs a group view plus site views. Show which approach you chose. -->

| Aspect | Small: Quillmere Analytics Ltd *(Example)* | Medium: Quillmere Health Systems *(Example)* | Large: Quillmere Group *(Example)* |
|---|---|---|---|
| Profile | 46 staff (38 employees, 8 contractors), B2B SaaS analytics, one office plus remote staff, one public cloud in two regions, processor of customer personal data | 320 staff, clinical scheduling software and managed service, two offices and a colocation suite, processor and controller | 2,400 staff, 6 sites in 4 countries (HQ, 3 plants, service centre, data centre), OT and IT, ISO 9001 and ISO 22301 certified |
| Who runs it | Part-time ISMS manager (0.5 FTE) with the CEO and CTO in one workshop | ISMS manager with security team, legal, DPO, operations and sales | CISO office with site security coordinators; group workshop plus one per site |
| Typical issue count | 8 to 12 issues, 6 to 8 parties | 15 to 25 issues, 10 to 15 parties | Group list plus site lists; 40 or more items in total |
| Key issues | Customer security questionnaires, cloud dependency, small team | Health data, hospital contracts, colocation legacy, supply chain duties | OT safety and availability, four legal systems, integration with existing ISO 9001 and ISO 22301 context analysis |
| Climate determination | Likely "not relevant" if all production is in cloud regions with failover and no party requires it, with a short reasoned record | "Relevant" in the worked example because of colocation cooling and tender criteria | Usually "relevant": plants and the data centre have physical exposure, and the group already analyses climate under its other ISO systems |
| Interfaces | Cloud provider, a few SaaS tools | Cloud, colocation, EHR platforms, monitoring provider | Intra-group interfaces between sites and shared services, OT vendors, many suppliers |
| Document form | This template, short tables | This template in full | One group document reusing the integrated management system context analysis, with an ISMS-specific annex per site |

## 13. Records and evidence

<!-- Guidance: Name the records that show the analysis really happened and is used. Keep them where the documented information register says. Auditor check: workshop evidence, approval, and use in scope and risk documents. -->

| Record | What it proves | Owner | Where kept | Retention |
|---|---|---|---|---|
| Approved version of this document | Issues, parties and requirements determined and approved | [@isms-manager] | [Document system] | Current plus superseded versions for one certification cycle (3 years) |
| Workshop attendance and notes | Analysis based on real inputs and the right people | [@isms-manager] | [Project folder] | 3 years |
| Climate change determination record (section 6.2) | Amd 1:2024 determination made with reasons | [@coo] | This document | Life of the ISMS |
| Legal, regulatory and contractual register entries | Requirements adopted are tracked | [@legal-counsel] | DOC-ISMS-014 | Per register rules |
| Management review minutes referencing changes | Changes in issues and parties reviewed (9.3.2) | [@isms-manager] | DOC-ISMS-085 | 3 years |

Map these records in the control evidence matrix (DOC-ISMS-033,
`isms/control-evidence-matrix`) under clauses 4.1 to 4.3 and list the
document in the documented information register (DOC-ISMS-028).

## 14. References

<!-- Guidance: Cite editions exactly. Laws are international examples, not a compliance list: your legal register holds the laws that apply to you. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022, ISMS requirements | 2022, https://www.iso.org/standard/82875.html | Clauses 4.1 to 4.3, 6.1.1, 9.3.2 |
| ISO/IEC 27001:2022/Amd 1:2024, climate action changes | 2024-02-23, https://www.iso.org/standard/88435.html | Climate change in 4.1 and note in 4.2 |
| ISO/IEC 27000:2026, overview | 2026, https://www.iso.org/standard/84257.html | Concepts |
| ISO/IEC 27003:2017, ISMS guidance | 2017, https://www.iso.org/standard/63417.html | Explanation of clause 4; a revision is in progress, check for a newer edition |
| ISO 31000:2018, risk management | 2018, https://www.iso.org/standard/65694.html | Establishing the context in enterprise risk |
| Regulation (EU) 2016/679 (GDPR) | 2016, check the consolidated text on EUR-Lex | International example of data protection law |
| Directive (EU) 2022/2555 (NIS2) | 2022 | International example of a cybersecurity law with supply chain duties |

Related templates: `compliance/ms-scope`, `compliance/legal-register`,
`compliance/risk-methodology`, `compliance/risk-register`,
`compliance/objectives-register`, `isms/isms-process-map`,
`isms/supplier-register`, `isms/data-centre-colocation-assessment`,
`compliance/management-review`, `isms/control-evidence-matrix`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024, clauses 4.1, 4.2
and 4.3, including the 2024 climate action changes. The method, tables,
questions, worked examples and guidance are original text. No ISO or IEC
text is reproduced; read the official standard, sold by ISO, IEC and
national standards bodies, for the exact requirements. Check the current
edition and any further amendments before use. This is a documentation
format, not certification or legal advice. Template licence: MIT.