Information Security Incident Management Policy

1. Purpose

This policy sets the rules for finding, reporting, assessing, responding to and learning from information security events and incidents, so that harm to the Organisation, its customers and the individuals whose data it holds is limited, and so that legal and contractual reporting duties are met on time.

• Every event that may affect confidentiality, integrity or availability reaches a trained responder quickly.
• Every incident is prioritised in the same way, so that the most serious get the fastest response.
• Evidence is preserved, decisions are recorded and lessons are turned into corrective actions that are tracked to closure.
• Reporting to customers, regulators and authorities follows a defined route and clock.

2. Scope

The policy applies to all employees, contractors and third parties who use or manage the Organisation's information, systems, facilities and services, and to incidents on systems the Organisation operates for customers.

• In scope: security events and incidents involving information, systems, networks, cloud services, devices, premises, people and suppliers, whether accidental or deliberate, and whether discovered by the Organisation or reported by others.
• In scope: personal data breaches, which also follow the Data Protection and Privacy Policy.
• In scope: events at suppliers that affect the Organisation's information or services.
• Out of scope: faults with no security effect (these follow the service incident route in the Incident Management Procedure), and routine requests for access or advice.

3. Terms and Definitions

4. Roles and Responsibilities

5. Incident Management Policy Statements

Detailed steps, forms and time targets are in the Incident Management Procedure. The statements below set the rules that the procedure must meet.

5.1 Principles

• All personnel must report any suspected security event immediately. No one is penalised for reporting in good faith, including when the report concerns their own mistake.
• The service desk must be reachable by at least [two channels, such as telephone and a monitored mailbox], and the numbers and addresses must be on the intranet, in the induction pack and on the back of staff access cards.
• A single incident record, in the ticketing tool, is the source of truth. Verbal or chat actions must be written into it within [1 hour].
• Containment takes priority over investigation, unless containment would destroy evidence that cannot be obtained another way, in which case the incident commander decides and records the reason.
• Incident information is confidential. It is shared only with those who need it, and only the communications lead speaks externally.
• A response plan and contact list must exist for each of the incident types, including customer-impacting and personal data incidents.

5.2 Incident types

The Organisation uses the types below to classify incidents, to select the right playbook and to report trends. An incident may have more than one type.

5.3 Priority

Priority sets the speed and level of attention. It is set by the service desk when logging and confirmed by the incident response team within [30 minutes], and is changed when facts change. The priority is shown in the incident record with the reason.

5.4 Response and resolution times

The times below apply to the priority in force. The clock starts when the incident is logged and runs outside business hours for P1 and P2. If the time to resolve cannot be met, the incident commander must tell the service owner and top management before the time runs out and record the new target.

5.5 Categorisation

The service desk selects a category to route the incident to the right resolver. The categories reflect the asset or capability affected, not the cause, which is recorded later.

5.6 Priority determination

Priority is set from the impact on the business and individuals, and the spread or urgency. The matrix below gives the starting priority. The incident response team may raise it, but lowers it only with the Head of IT Security's agreement.

• Impact is high where any of these apply: sensitive personal data of [more than 100] individuals or any customer data; loss of a customer-facing service for more than [30 minutes]; a financial loss over [a threshold set by finance]; a legal reporting duty; likely media attention.
• Urgency is urgent where the cause is still active, spreading or unknown, or where a notification deadline is running.
• An incident that is part of a wider campaign, or touches privileged accounts, must be raised by at least one level.

5.7 Reporting and corrective action

Each incident follows the stages below. The Incident Management Procedure gives the steps and forms for each.

5.7.1 Detection and reporting

• Personnel must report within [1 hour] of noticing a suspected event; they must not investigate it themselves, delete evidence or alert the suspected person.
• Monitoring tools must raise alerts to the security operations team, with tuned rules for the incident types; alerts that may be incidents must be triaged within the time to respond for their priority.
• Reports from customers, suppliers, researchers and the public must be accepted through a published security contact and logged like internal reports.

5.7.2 Logging and triage

• The service desk must record: reporter, date and time, what was seen, systems and data possibly involved, and the first priority and category.
• A responder must confirm whether the event is an incident, within the time to respond, and record the decision. Events that are not incidents are closed with a reason.
• Duplicates must be linked to a parent incident.

5.7.3 Containment

• The responder must choose the least disruptive action that stops the spread: isolate the device, disable the account, block the address, revoke the key or suspend the integration.
• Actions that will take a customer-facing service offline need the service owner's approval, which the incident commander may obtain verbally and record afterwards for P1.
• Containment steps must be written down with the time and who did them.

5.7.4 Investigation and evidence handling

• Evidence must be collected with methods that keep it intact: disk and memory images, logs, email headers, screenshots and configuration copies, hashed and stored in a read-only location with the chain of custody recorded.
• Logs relevant to an incident must be copied out of rotation immediately and held for the life of the incident and [12 months] after it.
• Evidence must be handled only by people named in the incident record. Where criminal or civil action is possible, Legal decides whether an external forensic firm is engaged.

5.7.5 Eradication and recovery

• The cause must be removed and the system rebuilt from a known-good state where compromise cannot be excluded.
• Credentials, keys and tokens that may have been exposed must be rotated before the service is returned to use.
• Recovery must be tested by the service owner and monitored for [7 days] at a heightened alert level before closure.

5.7.6 Communication

• The incident commander must set the contacts list and the update rhythm from the table of response times, and updates must go to the service owner, top management and the Privacy Lead.
• Customers must be told as the contract requires, and in any event within [24 hours] of confirmation that their data or service was affected. The communications lead approves every external message.
• Law enforcement is engaged on the decision of top management and Legal.

5.7.7 Closure and review

• An incident closes only when containment, eradication and recovery are complete, evidence is stored, communications are done, and the record is complete.
• A post-incident review must be held within [5 working days] of closure for P1 and P2, and within [15 working days] for P3 where there is a lesson to learn. It covers timeline, root cause, what worked, what did not and the corrective actions.
• Reviews must be blameless in tone and factual in content.

5.7.8 Corrective action plan

5.8 Major incident management

A P1 incident is run as a major incident. The incident commander opens a dedicated bridge (a call and a chat channel), names a scribe, and sets the roles below within [30 minutes] of the P1 being declared.

• A handover must be held at least every [8 hours] so that no one works for longer than [12 hours] without rest.
• The commander must declare a stand-down only when the service owner has accepted the restored service and monitoring is in place.

5.9 Escalation

5.10 Learning and trend reporting

• The Head of IT Security must report incident numbers by type, category, priority, cause and time to resolve to top management [quarterly], with the five most important lessons and the status of corrective actions.
• Repeating incidents, or several incidents with the same cause, must be raised to the Problem Management Policy and Process and to the risk register.
• Lessons that change what staff should do must be turned into a short awareness message within [30 days].

5.11 Cybersecurity incidents

• A cyber incident of a type listed in the CERT-In Directions of 28 April 2022 must be reported to CERT-In within 6 hours of the Organisation noticing it or being told of it [confirm the current requirement]. The Head of IT Security reports, and the incident commander must start the clock from the logged time of notice.
• ICT system logs must be enabled and kept for 180 days, within Indian jurisdiction, and produced to CERT-In on request [confirm the current requirement].
• Where the Organisation operates in other jurisdictions, Legal must maintain the list of reporting duties under applicable law in each, and the incident commander must check it on every P1 and P2.
• The Organisation must maintain a named contact point for the national cyber incident authority and for law enforcement, and test it [every 6 months].
• The Organisation must maintain contact with special interest groups and trusted industry bodies for threat information, and share indicators of compromise only after Legal and the Head of IT Security approve.
• Ransomware demands must not be paid without top management approval, taken with Legal advice and law enforcement guidance.

5.12 Personal data incidents

• Incidents that involve personal data follow this policy and the breach management statements in the Data Protection and Privacy Policy. The Privacy Lead must be alerted within [30 minutes] of any incident marked as involving personal data.
• A decision on notification of the Data Protection Board and affected individuals must be recorded for every personal data breach, including when the decision is not to notify [confirm the current requirement].

5.13 Supplier incidents

• Contracts with suppliers who hold or can reach the Organisation's information must require notice of incidents within [24 hours] and cooperation in the investigation.
• The supplier owner must treat a supplier incident as an incident in the Organisation's own process, and must assess whether the Organisation's data or services are affected.

5.14 Incident Management Plan Revision and Testing

The incident management plan, playbooks and contact lists must be tested and updated to keep them useful.

• Findings from tests and real incidents must change the plan within [60 days].
• The plan must be tested again after any major change to the environment, the team or the law.

6. Compliance and Monitoring

7. Records and Evidence

Annexure A: Incident report form

Annexure B: Incident register

Annexure C: Post-incident review template

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

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

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

• Incident Management Procedure
• Data Protection and Privacy Policy
• Logging and Monitoring Policy
• Problem Management Policy and Process
• Information Security Aspects of Business Continuity Policy
• Threat Intelligence Policy