The incident response plan, written from a few answers

# Information security incident response plan: [company]

Incident lead: [the incident lead] · Deputy: [the deputy] · Approved by: [top management]

Written on  with the free page on getstandardos.com against the Annex A controls on incident management of ISO/IEC 27001:2022. The wording is StandardOS's own; the regulatory clocks are read from the package that also drives the GDPR, NIS2 and CRA clock pages.

## 1. Purpose and scope

This plan says what [company] does from the moment an information security event is noticed until the incident is closed and its lessons are applied. It covers every system, service and location inside the scope of the management system, every person working under the company's control, and the suppliers whose incidents reach the company's data or customers.

## 2. Roles

- [the incident lead] leads every incident: declares it, sets the severity, runs the response, decides on notifications, closes the incident and owns the review afterwards.
- [the deputy] deputises when the lead is unavailable, with the same authority, and the two are never both unreachable on the same day.
- Everyone reports: any person who notices an event reports it at once through the channel below, and nobody needs permission to report.
- Only [the incident lead] or top management speaks to customers, authorities or the press about an incident; nobody else confirms or denies one.

## 3. Reporting an event

An event is reported through [to be completed], at any hour. A report is never wrong for being early or for turning out to be nothing; an event that was seen and not reported is the failure.

A report says what was seen, where, when, by whom, and what has already been done; it does not wait for the cause or the impact to be known.

## 4. Assessment and severity

[the incident lead] decides within the hour whether the event is an incident and sets one of three severity levels, revised as the picture changes:

- Low: one system or one person affected, no personal data or customer data exposed, no service down; handled by the team in office hours, reviewed at the next weekly meeting.
- Medium: customer data or a customer-facing service affected, contained inside the day; the lead runs it, customers whose data or service is touched are told, the regulatory clocks are checked.
- High: confirmed exposure of personal data, a service down for customers, ransomware or an attacker with access; all hands, top management informed within the hour, the regulatory clocks start, outside help engaged where the team cannot contain it alone.

## 5. The response

1. Contain: stop the spread first, isolate the system, revoke the credential, block the address, take the service offline if it has to be; containment before understanding.
2. Assess: establish what happened, what is affected, whether personal data or customer data is involved, and since when; write it down as it is learned, with the time of each finding.
3. Eradicate: remove the cause, the malware, the account, the vulnerability, the misconfiguration, and confirm it is gone before restoring anything.
4. Recover: restore from known-good backups or rebuild, verify the service, watch it closely for the days after, and lift the containment steps in order.
5. Communicate: keep an incident log open from the first minute, tell the people inside the company who need to act, and tell customers, authorities and partners what the plan and the clocks below require, in that order.

Tooling: [to be completed].

## 6. Notifications and regulatory clocks

Every clock below runs from the moment of awareness, not from the moment the cause is found; the lead records that moment in the log when the incident is declared.

[No regulation was selected. If the company holds personal data, is an essential or important entity, makes a product with digital elements or serves financial entities, the corresponding clock belongs here.]

Outside the company we tell: [to be completed].

## 7. Evidence

From the first minute the lead preserves what a later inquiry, an insurer, an authority or a court may need: the incident log with times, the logs and alerts as exported copies, disk and memory images where an attacker was present, the messages sent and received, and the decisions with who took them; originals are kept unchanged, copies are worked on, and the chain of who held what is recorded.

## 8. Learning from the incident

Within 10 days of closing an incident of medium or high severity, [the incident lead] holds a review with the people involved: what happened, what worked, what did not, and which control, procedure or training let it happen. Each cause becomes a corrective action with an owner and a date, and the incident and its actions are an input of the next management review.

## 9. Exercises

The plan is exercised once a year as a tabletop on a written scenario, with the lead, the deputy and the people who would act, and the plan is changed where the exercise shows it wrong.

## 10. Records

Every reported event, whether it became an incident or not, is recorded with its date, its assessment and its outcome; the incident log, the notifications sent and the review are kept as documented information of the management system, available to the certification body, and counted in the management review.

Approved by [top management] on [date]. Reviewed after every high-severity incident, after every exercise, and at least once a year.

This plan is written from the answers given. It is not certification or legal advice; the certification body reads the plan for the roles, the procedure, the records and the evidence that it is followed, and the regulatory clocks are read against the regulations themselves.