Incident Management Procedure

1. Purpose

This procedure gives the Organisation one route for dealing with anything that threatens the confidentiality, integrity or availability of its information or services. It fixes who may declare an incident, how serious it is judged to be, who must act, how quickly, what must be told to customers, authorities and individuals, and how the lessons are fed back.

It supports the Information Security Incident Management Policy and is the operating document for the incident response team.

2. Scope

• In scope: every information security event, weakness and incident affecting the Organisation's information, systems, networks, premises, people or suppliers, including those occurring in cloud services and at suppliers on the Organisation's behalf.
• In scope: events involving customer data and personal data, and events at customers' environments that the Organisation operates or supports.
• Out of scope: general IT faults with no security aspect, which follow the Problem Management Policy and Process; if such a fault turns out to have a security cause, it enters this procedure at once.
• Applies to: all employees, contractors and third parties with access, and to the incident response team and its leaders.

3. Terms and definitions

4. Roles and Responsibilities

5. Incident Management Governance and Team

5.1 Governance

• The Head of Information Security owns the process. Senior management reviews incident statistics, repeat causes and open actions at least every [quarter].
• An incident response team (IRT) exists as a standing group with named members and deputies. Its contact list is checked every [3 months] and held offline as well as online.
• A single incident has one incident manager. Authority to take systems offline is pre-agreed for Severity 1 and 2 incidents in the severity matrix.
• Roles are assigned so that someone who is part of the cause of an incident does not investigate it alone.
• An external forensic and response provider is retained under a contract that gives response within [4 hours], with confidentiality terms agreed in advance.

5.2 Incident response team structure

Deputies are named for each role. During an extended incident, shifts are planned so that no one works more than [12 hours] without rest, and handover notes are written at each change.

5.3 Contact with authorities and special interest groups

The Legal lead keeps up-to-date contacts for the national cyber authority, the data protection authority, law enforcement, sectoral regulators, insurers, and relevant information-sharing groups. Contact is made only through the Legal lead or the IRT lead, and each contact is recorded in the incident file.

6. Types of Events

7. Incident Severity Matrix

7.1 Severity levels and targets

7.2 Factors used to set severity

• Sensitivity and volume of data affected, including whether personal data or customer data is involved.
• Number and criticality of systems and services affected, and effect on customers and their commitments.
• Whether the attack is ongoing, how far it has spread, and whether the attacker has privileged access.
• Legal, regulatory or contractual duty to notify, and likely reputation or financial loss.
• Ability to recover from backups, and time to restore.

8. Preparing for Cybersecurity Incidents

8.1 Playbooks

A playbook gives a short, tested, step-by-step response for a common scenario, so that responders do not have to design the response under pressure. Each playbook states trigger, severity, roles, containment, eradication, recovery, evidence, communications, and exit criteria.

Playbooks are tested by a tabletop exercise at least [once a year] for the most serious scenarios, and the results lead to updates. They are held where responders can reach them even if systems are down.

8.2 Configuring devices and systems to support response

8.3 Training staff on incident response

• All staff learn in induction and each year how to recognise and report an event and what not to do (do not delete, do not investigate alone).
• IRT members complete role training when they join and attend an exercise at least [twice a year]; at least one exercise involves senior management.
• Service desk staff are trained to spot security signs in ordinary calls and to open a security ticket.
• Attendance and exercise results are recorded; findings are tracked to closure.

9. Detecting and Reporting Events and Weaknesses

9.1 Signs of an incident

9.2 Incident triggers

Any one of the following triggers moves an event into formal assessment under this procedure.

• An alert from a monitoring or detection tool that matches a rule rated High or Critical and cannot be explained as normal within [30 minutes].
• A report from any person, internal or external, that credentials, data, devices or systems may be compromised.
• A failed or bypassed control, such as a firewall rule open to the internet, a disabled endpoint agent, or a failed backup of critical data.
• Evidence of unauthorised change to configuration, code or data.
• Notification from a supplier, customer, researcher, authority or the media.
• A vulnerability rated Critical that is being exploited or for which an exploit is public, and which cannot be patched within [72 hours].
• Discovery of personal data in an unauthorised place or sent to the wrong party.

9.3 Reporting by personnel

1. NoticeThe person who sees something unusual stops using the affected device or account only if safe, and does not delete files, restart or investigate alone.
2. ReportReport at once, and in any case within [1 hour] of noticing, to the service desk by [phone, the security mailbox or the ticketing portal], with what was seen, when, and on which system.
3. LogThe service desk opens an incident ticket and flags it Security within [15 minutes]. Anyone may report outside hours by the on-call number.
4. TriageThe security analyst contacts the reporter within the time target of the provisional severity and records the first assessment.
5. FeedbackThe reporter is told the outcome. Reporting in good faith is never penalised, and the reporter's identity is kept confidential on request.

9.4 Reporting a personal data breach

Any suspected exposure of personal data is reported as above, and the service desk adds the label Privacy so that the Data Protection Officer is alerted. The Data Protection Officer begins an assessment within [2 hours] of notice.

1. Establish factsWhat data, how many people, what happened, since when, and whether it is still happening.
2. Assess harmJudge likely harm to individuals: identity theft, financial loss, discrimination, distress, danger to safety. Children's data and sensitive data raise the risk.
3. ContainStop further exposure: recall, revoke access, take down public content, change credentials.
4. Decide on notificationThe Data Protection Officer, Legal and senior management decide whether to notify the data protection authority and the individuals, as the Digital Personal Data Protection Act, 2023 and its Rules and any other applicable data protection law may require [confirm the current requirement]. Decision and reasons are recorded within [24 hours] of confirming a breach.
5. NotifyNotices to the authority state the nature of the breach, likely consequences, measures taken and a contact point. Notices to individuals are in plain language and say what they should do. Where the Organisation acts as processor, the customer is told within the time in the contract.
6. RecordEvery breach, including those not notified, is logged in the incident register with the reasoning.

9.5 Reporting to the national cyber authority

The Organisation reports qualifying cyber incidents to CERT-In within 6 hours of noticing them, as the CERT-In Directions of 28 April 2022 require [confirm the current requirement]. The Legal lead and the IRT lead check the current list of reportable incident types and the format before every report [confirm the current requirement].

1. NoticeThe time of first noticing by any person is written in the register as the start of the reporting period, even if severity is not yet agreed.
2. ClassifyWithin [2 hours] of noticing, the incident manager and Legal decide whether the incident is of a type that must be reported to CERT-In [confirm the current requirement]. When in doubt, report.
3. PrepareFill the report with what is known: date and time, systems and services affected, nature of the incident, indicators, impact, actions taken and a contact. More detail follows later; an incomplete report is better than a late one.
4. SubmitThe Legal lead or the IRT lead submits the report through the channel the authority specifies and records the reference and the time.
5. Follow upProvide updates and information the authority asks for. Close with a final report.
6. Keep logsICT system logs are kept for 180 days within Indian jurisdiction and provided on request, as the CERT-In Directions of 28 April 2022 require [confirm the current requirement].

9.6 Reporting to customers, regulators and other parties

10. Assessment and Response

10.1 Assessment of information security events

1. ReceiveThe analyst on duty receives the ticket or alert and checks it for duplicates. Target: within the acknowledgement time of the provisional severity.
2. GatherCollect basic facts: who, what, where, when, how found, affected data and systems, and any indicators. Use logs, alerts and the reporter.
3. ClassifyDecide whether it is a false positive, an event, a weakness or an incident, and its type from the event types table.
4. RateApply the severity matrix and record the reasons. For Severity 1 or 2, the analyst calls the IRT lead at once.
5. DeclareThe IRT lead (Severity 1 and 2) or the security manager (Severity 3 and 4) declares an incident, appoints an incident manager and opens an incident record in the register.
6. NotifyTell the owner of the system, the Data Protection Officer if personal data may be involved, and Legal if law or contract may apply.
7. DecideAgree the response plan and, if needed, the playbook to follow. False positives are closed with an explanation and used to tune detection.

10.2 Response to incidents

1. ContainStop spread: isolate hosts, block accounts and addresses, disable access. Choose short-term actions that protect evidence, and record every action with a time.
2. Preserve evidenceBefore changes, copy logs and take images of memory and disks where needed. Maintain chain of custody; evidence is stored in a protected location with limited access.
3. InvestigateIdentify entry point, extent, data touched, accounts used and persistence. Search for the same indicators across the environment.
4. EradicateRemove malware, close the entry point, rotate credentials and keys, and patch or reconfigure as needed.
5. RecoverRestore from clean backups or rebuild, validate integrity, return to service in stages with extra monitoring for [14 days]. Follow the BCP and DR Procedure when the service is disrupted.
6. CommunicateUpdate stakeholders at the frequency in the severity matrix and keep a single source of facts.
7. CloseClose when the threat is removed, systems are restored, notifications are done and actions are assigned. The IRT lead approves closure of Severity 1 and 2.

10.3 Handling evidence

• Only trained responders collect evidence, using documented methods and trusted tools.
• Each item is labelled with description, date, time, collector and hash, and stored in a locked or restricted location with access logged.
• Original evidence is never worked on directly; analysis uses copies.
• Evidence needed for disciplinary or legal action is kept under legal hold until Legal releases it; otherwise per the retention schedule in the Documents and Records Management Procedure.

10.4 Learning from incidents

1. ReviewThe incident manager holds a blameless review within [10 working days] of closure for Severity 1 and 2 and monthly in batch for others, with all roles involved.
2. AnalyseEstablish timeline, root cause, contributing factors, what worked, what failed and the cost in time and money.
3. ActRaise corrective actions in the ticketing tool, each with an owner and date; update playbooks, rules, training and risk register.
4. ShareShare anonymised lessons with staff and, where appropriate, trusted information-sharing groups.
5. TrackThe Head of Information Security reports actions open past due to management each quarter.
6. TrendEach quarter, analyse the register for repeat types, causes and slow steps; link to the risk register and to problem management.

11. Escalation and On-call Arrangements

• A rota of trained responders covers all hours for Severity 1 and 2. The on-call phone numbers are held by the service desk and tested every [month].
• If the person called does not respond within [15 minutes], the service desk calls the deputy, then the next in the contact list.
• A person on call has a laptop, secure remote access, the playbooks and a copy of the contact list available offline.
• Responders are told in advance which actions they may take without further approval, such as isolating a host or disabling an account.
• Time spent on call is recognised under HR rules, and long incidents are staffed in shifts.

12. Incidents Involving Suppliers and Customers

1. Supplier incidentA supplier that finds a breach affecting the Organisation must tell the vendor owner within [24 hours] as the contract requires. The vendor owner opens an incident ticket and the IRT treats it as an event on the Organisation's own estate.
2. Assess exposureIdentify what data, credentials, integrations and network paths the supplier has. Suspend or restrict them until the supplier gives assurance.
3. Gather evidenceRequest the supplier's incident report, indicators and timeline in writing. Ask for confirmation of containment and of the date of resolution.
4. Customer incidentWhen the Organisation's service or staff are implicated in a customer's incident, the account owner tells the incident manager at once, and the customer's contacts are agreed with Legal.
5. Joint responseName a single point of contact on each side, agree how often facts are shared, and decide who talks to regulators and the public.
6. Follow upRecord supplier performance in the supplier register and take the issue to the next review under the Supplier Relationship Management Procedure.

13. Communication During an Incident

• Facts only: say what is known, what is not known and when the next update will come. Do not guess about cause or blame.
• One spokesperson speaks for the Organisation; staff refer all outside questions to the Communications lead.
• Use the out-of-band channel if email and chat may be compromised, and do not discuss the incident on open channels.
• Messages to customers are cleared by Legal and the Data Protection Officer before sending and are kept in the incident file.
• Internal staff are told what to do and what to avoid, for example not to open an attachment, to change a password or to stay offline.

14. Weaknesses and Near Misses

A weakness found by a person, a scan, an audit or a researcher is reported through the same channel and tracked as an event of Severity 4 unless it is already being exploited. The security analyst records it, rates its risk with the system owner and sets a due date for the fix. Critical weaknesses are handled under the vulnerability and patch procedures within [72 hours], and a weakness found to be exploited becomes an incident. Near misses are recorded because they show control failures at no cost; the quarterly review looks at their causes.

15. Incident Closure Criteria

1. The threat is contained and removed, and monitoring shows no further activity for [14 days] (Severity 1 and 2) or [3 days] (others).
2. Affected systems are restored or replaced and have passed an integrity check.
3. Credentials, keys and tokens that may have been exposed are changed.
4. All required notices are sent and the references are in the incident file.
5. The register is complete, including cause, impact, timeline and cost.
6. Evidence is stored, with legal hold applied where needed.
7. Corrective actions are raised with owners and dates, and the review is booked.
8. The incident manager and the IRT lead (for Severity 1 and 2) approve closure in the register.

16. RACI Matrix

17. Measures

18. Records and evidence

Annexure A: Incident register

Annexure B: Incident report form

Annexure C: Post-incident review template

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

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

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

• Information Security Incident Management Policy
• Data Protection and Privacy Procedure
• Logging and Monitoring Procedure
• BCP and DR Procedure
• Threat Intelligence Policy
• Problem Management Policy and Process
• Malware Protection Policy
• Supplier Relationship Management Procedure