Internal and External Issues and Interested Parties

1. Purpose

This statement records the external and internal issues that are relevant to the Organisation's purpose and that affect its ability to achieve the intended outcomes of the ISMS, and the interested parties with requirements that the ISMS must take into account. It is the controlled input to the ISMS scope, the risk assessment, the objectives and the management review.

• Make visible what in the environment could change the Organisation's information security risk.
• Show which party expects what, and which expectations have become legal, contractual or voluntary commitments.
• Give the Information Security Steering Committee one list to review at least every [12 months].

2. Scope

The statement covers the whole ISMS scope set out in the ISMS Manual. It applies to the Head of Information Security, who maintains it, and to every function head who supplies issues and party requirements for their area.

• In scope: external issues, internal issues, interested parties and their requirements, the rating of each, and the actions linked to them.
• Out of scope: the detailed risk analysis (in the Risk Management Policy) and the detailed legal register for each country, which Legal and compliance keeps and which this statement summarises.

3. Terms and Definitions

4. Roles and Responsibilities

5. How Issues and Parties Are Determined and Kept Current

1. CollectThe Head of Information Security gathers input from function heads, Legal and compliance, audit and incident reports, customer contracts and questionnaires, regulator publications, threat reports and staff surveys. Time target: [20 working days] before the annual review.
2. ClassifyEach item is assigned to a category in this statement and marked external or internal, or as a party requirement.
3. RateThe item is rated for its effect on the ISMS using the scheme below. Output: updated register.
4. LinkEach rated item is linked to a risk, an objective, a control or an opportunity. An item with no link is questioned: either it does not matter or a response is missing.
5. Approve and communicateThe ISSC reviews the statement; top management signs off changes to the scope. The approved version is published to the document owners listed in related documents.
6. MonitorBetween reviews, any person may raise a change; the Head of Information Security updates the register within [10 working days] and tells the risk manager if a rating changes.

• Triggers for an immediate review: a new or changed law or regulation; a new customer type, market or product; a merger, acquisition or reorganisation; a significant incident; a change of a critical supplier; a major technology change; a new certification or contractual security schedule.

6. Rating of Issues

7. External Issues

External issues are conditions outside the Organisation's control that affect its information security. Each row of the tables is carried into the issues register (Annexure A) with a rating, an owner and a link.

7.1 Legal and regulatory requirements

Legal and compliance reviews this table [every 6 months] and whenever the law changes. A requirement that applies is added to the compliance register and assigned an owner.

7.2 Threat landscape and technology

• Rising volume of ransomware, phishing, credential theft and supply chain attacks, reported by the national computer emergency response team and sector bodies. Response: Threat Intelligence Policy, Malware Protection Policy, Patch Management Policy.
• Rapid adoption of cloud, remote working and artificial intelligence tools, which move data outside the traditional perimeter. Response: Cloud Computing Security Policy and Procedure, Mobile Device and Teleworking Policy, Employee AI Usage Policy, AI Governance Policy.
• Shorter time between disclosure of a vulnerability and its exploitation. Response: Vulnerability Assessment and Penetration Testing Procedure; Patch Management Procedure.
• Dependence on a small number of platform and cloud providers. Response: concentration risks in the Risk Management Policy.

7.3 Customers and market

• Customers increasingly require evidence of assurance, short breach notice windows and the right to audit. Response: contract review, assurance responses by the Head of Information Security.
• Competitors and tenders that require recognised security standards. Response: maintain the ISMS and its evidence.
• Reputation is shaped by public incidents in the sector. Response: Information Security Incident Management Policy communication rules.

7.4 Supply chain and economic conditions

• Critical services depend on suppliers whose own security may change. Response: Supplier Relationship Management Procedure.
• Budget pressure may reduce security investment or staffing. Response: the annual security plan and risk-based prioritisation under the Risk Management Policy.
• Labour market shortages for security skills. Response: competence plan and succession cover under the HR Succession Planning Policy.

8. Internal Issues

Internal issues are conditions within the Organisation that affect its information security.

8.1 Governance, strategy and culture

• Top management sponsorship, the strength of the Information Security Steering Committee and the pace of decision making.
• Business strategy: growth, new services and acquisitions that change what must be protected.
• Security culture: the rate at which staff report events, complete training and follow policy, measured in the metrics pack.

8.2 Employees

The workforce is both the largest source of risk and the most important control. Issues include the number of new joiners and leavers, reliance on contractors, remote working, skill gaps in security roles, attrition in key roles, morale and workload.

• Screening, contracts and exits: HR Security Policy and HR Security Procedure.
• Awareness and competence: ISMS Manual section 7.
• Acceptable behaviour: Acceptable Usage Policy.

8.3 Security standards and frameworks

The Organisation has chosen to align to ISO/IEC 27001 and may follow other frameworks that customers or regulators expect. Each commitment adds requirements, audit obligations and evidence that must be kept.

• Commitments are recorded in the compliance register with the owner, the audit date and the evidence location.
• Where frameworks overlap, controls are mapped once in the Statement of Applicability so that one test serves several requirements.

8.4 Vulnerability management

The state of the Organisation's own vulnerabilities is an internal issue because it drives likelihood in every risk assessment: the age of the technology estate, unsupported systems, the size of the patch backlog, the quality of the asset register and the findings of recent testing.

• Measures: critical vulnerabilities outside the patch window, assets not in the register, systems past support dates.
• Response: Patch Management Policy, Secure Configuration Policy, Vulnerability Assessment and Penetration Testing Procedure.

8.5 Technology estate and resources

• Legacy systems, shadow IT, complexity of integrations, and dependence on individuals for key knowledge.
• Tool coverage and licence limits for monitoring, endpoint protection and backup.
• Capacity of the security and IT teams compared with the workload, tracked in the objectives register.

9. Interested Parties

The table lists the parties relevant to the ISMS, what each needs and expects, and whether the requirement is adopted as a compliance obligation. The detail for each party follows.

9.1 Legal, regulatory and government bodies

Regulators expect the Organisation to know and meet its legal duties, to report incidents within the required time, and to co-operate with inquiries. Only Legal and compliance or a person it authorises may communicate with a regulator. The Organisation keeps the contact list under the ISMS Manual.

• Requirement: report cyber incidents to the national computer emergency response team within 6 hours of noticing them, as the CERT-In Directions of 28 April 2022 require [confirm the current requirement].
• Requirement: keep ICT logs for 180 days within Indian jurisdiction [confirm the current requirement].

9.2 Data subjects

Data subjects expect that personal data is collected for stated purposes, kept accurate and secure, not kept longer than needed, and that they can ask for access, correction and erasure. These expectations are met by the Data Protection and Privacy Policy and the Data Protection and Privacy Procedure. Requests are answered within the time the law requires or [30 days].

9.3 Customers

Customers expect the service to be available, their data kept confidential, incidents reported to them within the contract time or [72 hours], and the Organisation to answer security questionnaires and, where agreed, allow audits. Each customer's security terms are held in the contract register and mapped to controls by the Head of Information Security.

9.4 Vendors and suppliers

Vendors expect clear security requirements before the contract, a single point of contact, and fair treatment when they report a problem. The Organisation expects them to meet the requirements it sets in the Supplier Relationship Management Policy and Supplier Relationship Management Procedure, to notify incidents within [24 hours], to flow requirements to sub-suppliers, and to allow review of controls.

10. Use of This Statement in the ISMS

11. Compliance and Monitoring

The Head of Information Security reviews the register at least every [12 months] and before each management review, and checks every [quarter] that all High-rated items have a current link and owner. Internal audit samples the register each year to confirm the statement reflects the contracts and laws actually in force.

Annexure A: Issues register template

Annexure B: Interested-party register template

12. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

13. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

14. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• ISMS Manual
• Risk Management Policy
• Information Security Policy
• Data Protection and Privacy Policy
• Supplier Relationship Management Policy
• ISMS Compliance Scheduled Activities Plan
• Information Security Monitoring and Compliance Policy