An incident plan earns its keep in the first hour. Annex A asks you to prove it would.

1. 6.8
   Information security event reportingGive everyone a simple, known route to report something that looks wrong, quickly.
2. 5.24
   Information security incident management planning and preparationDecide roles, procedures and contacts before anything happens.
3. 5.25
   Assessment and decision on information security eventsLook at each reported event and decide whether it is an incident, and how serious.
4. 5.26
   Response to information security incidentsContain, fix and recover according to the procedures you wrote.
5. 5.27
   Learning from information security incidentsFeed what each incident taught back into controls and risk.
6. 5.28
   Collection of evidenceGather and keep evidence in a way that holds up if it is needed later.

An event is anything worth a look: an odd login, a lost laptop, an alert. An incident is an event you have judged to harm, or to threaten, the confidentiality, integrity or availability of information. Control 5.25 is the gate between them, and auditors check that the gate has written criteria.

Incident lead

Owns the response from triage to closure, makes the calls, keeps the timeline.

Technical responders

Investigate, contain and restore. Usually engineering or an outside response firm.

Communications owner

Speaks for the company to staff, customers and partners, using approved wording.

Legal and privacy

Decides on regulatory and contractual notices, and on handling of evidence.

Executive sponsor

Approves spending, shutdowns and external statements above the lead's authority.

In a small company one person may wear three of these hats. That is fine if the plan says so and names a deputy for each.

In India, the CERT-In directions issued under the IT Act set a short window for reporting certain incident types. Check them when you set Severity 1 and 2 notice rules; the CERT-In page in this library covers them.

1. Report: someone sees something and uses the known route (6.8).
2. Triage: the on-call person assesses it against written criteria and sets a severity (5.25).
3. Mobilise: the incident lead opens a record and calls the people the severity requires.
4. Contain: limit the spread, preserving evidence before wiping or rebuilding (5.26, 5.28).
5. Eradicate and recover: remove the cause, restore service, watch for return.
6. Notify: decide and send the notices that contracts and law require, with the decision recorded.
7. Review and close: hold the post-incident review and track its actions to completion (5.27).

The post-incident review

Hold it soon, while memory is fresh, and keep it blameless: the aim is the cause, not a culprit. Cover what happened, when it was noticed and why not earlier, what worked, what slowed the team, and which controls or risks should change. Actions get owners and dates in the same tracker as other corrective work.

• Capture before you clean. Take disk images, memory captures or log exports before rebuilding a machine, where the severity warrants it.
• Record the chain of custody. Who collected what, when, from where, and who has held it since.
• Protect integrity. Hash collected files and store them where they cannot be altered.
• Keep logs long enough. Retention that reaches back past the likely start of an intrusion.
• Know when to call specialists. If legal action or a regulator is likely, bring in forensic help early.

1. Scenario: an illustrative case such as a support engineer's account used from an unknown country to export customer tickets.
2. First injects: the alert arrives on a weekend. Who sees it, who is called, what severity is set?
3. Escalation: evidence suggests data left the system. Who decides on customer notice, and on what facts?
4. Complication: the incident lead is unreachable, or a journalist emails. Does the deputy and the comms owner act?
5. Debrief: list gaps in the plan, contacts and tools, and log each as an action with an owner.

What an auditor samples

• The incident plan, with roles, criteria and contacts current
• The event and incident log, and a sample of entries traced from report to closure
• A post-incident review and evidence that its actions were finished
• A drill record: scenario, attendees, findings, actions
• Proof that staff know how to report, such as awareness material or a reporting channel in use

• An empty log. No events recorded at all usually means nobody reports, not that nothing happened.
• Severity set by feel. Without written criteria, triage cannot be tested and 5.25 is weak.
• Reviews with no follow-through. Actions agreed and never closed undo the point of 5.27.
• Contacts out of date. A plan listing someone who left is the first thing a drill or an auditor finds.
• Evidence wiped in the rush. Rebuilding before capturing leaves nothing to examine later.

Sources: ISO/IEC 27001:2022 Annex A control names 5.24 to 5.28 and 6.8; ISO/IEC 27002:2022 as background (not quoted); NIST SP 800-61 on computer security incident handling and response; the ISO/IEC 27035 series on incident management; ISO/IEC 27037 on handling digital evidence; CERT-In directions under section 70B of the IT Act, 2000, named only. Severity levels, flow and drill are our own illustration.