ISMS Context and Interested Parties Template (ISO/IEC 27001 4.1 to 4.3)

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.

Document control

Approvals

Revision history

Contents

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

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

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).

3. Intended outcomes of the ISMS

4. External issues

5. Internal issues

6. Climate change determination

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

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

8. Requirements addressed through the ISMS

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

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

11. Monitoring, review and triggers

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:

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

12. Size tiers

13. Records and evidence

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

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.