Incident Response Policy

Document ID: ISMS-POL-004 | Version: 1.0 | Date: March 2026 | Classification: Internal | Owner: Chief Information Security Officer

Purpose and Scope

This policy establishes the framework for identifying, reporting, assessing, responding to, and learning from information security incidents at [Organisation Name], in accordance with ISO/IEC 27001:2022 Annex A controls 5.24–5.28.

It applies to all employees, contractors, and third parties who may detect, experience, or respond to a security incident. It covers all information assets within the ISMS scope, including client environments where the organisation provides managed security services.

1. Definitions

2. Incident Classification

All confirmed security incidents are assigned a severity rating at the time of detection. The ISM is responsible for initial severity assignment; the CISO may reassign severity as more information becomes available.

3. Incident Reporting Procedure

How to Report:

• Email: security@[organisation-domain].com (monitored 24/7 by SOC team)
• Phone: [Security Hotline Number] (for P1/P2 only; available 24/7)
• Service Desk: Submit a security incident ticket via the IT service desk portal
• Direct: Contact the ISM or any CISO team member directly for urgent incidents

What to Include in Your Report:

• What you observed (describe in plain language — do not use technical jargon)
• When you first noticed the issue (date and time, as accurately as possible)
• Which systems, files, or accounts appear to be affected
• What you did in response, if anything (e.g., “I closed the browser”, “I shut down the laptop”)
• Your contact details and availability

No-Blame Culture: The organisation operates a no-blame culture for security incident reporting. Staff who promptly and honestly report incidents will not face disciplinary action solely as a result of having reported. Delayed or concealed reports cause significantly more harm than the original incident — prompt reporting is always the right action.

4. Incident Response Phases

Phase 1 — Identify

• Detect the incident through monitoring, user report, or automated alert.
• Confirm it is a genuine incident (not a false positive).
• Assign an Incident ID and record in the Incident Register.
• Assign a severity rating per Section 2.
• Appoint an Incident Lead (ISM for P3/P4; CISO for P1/P2).
• Notify stakeholders per the escalation schedule.

Phase 2 — Contain

• Isolate affected systems to prevent lateral movement or further data loss (network isolation, account lockout, revoking API keys as appropriate).
• Preserve all evidence before taking containment actions where possible: take memory dump, capture live logs, photograph screens.
• Do not reboot or power off systems unless there is active data destruction in progress — forensic evidence may be lost.
• Apply temporary blocks (firewall rules, DNS sinkholing) to stop ongoing attacker communication.
• Document every containment action taken with timestamp and operator name.

Phase 3 — Eradicate

• Identify and remove the root cause: delete malware, close the exploited vulnerability, revoke compromised credentials.
• Identify the attack vector and confirm it has been closed — not just the symptoms.
• Apply emergency patches or configuration changes as required via expedited change management.
• Conduct a thorough scan of all potentially affected systems before proceeding to recovery.
• Confirm with the CISO that eradication is complete before beginning recovery.

Phase 4 — Recover

• Restore affected systems from a verified clean backup taken prior to the incident.
• Validate restored systems for integrity before reconnecting to the network (check file hashes, run AV/EDR scan, review logs).
• Reintroduce systems to production in a phased manner; monitor closely for 72 hours post-recovery.
• Communicate restoration status to clients and stakeholders with estimated timelines.
• Confirm service continuity and that all affected services are operating normally before declaring the incident resolved.

Phase 5 — Communicate

• Notify affected clients if their data may have been accessed, disclosed, or lost — do not delay notification while investigating; provide what is known and commit to updates.
• Notify regulators within the required timeframe if the incident constitutes a reportable data breach (see Section 7).
• Provide regular status updates to senior management throughout P1/P2 incidents (minimum every 2 hours until resolved).
• Prepare external communications (press statement, client notification letter) with legal review before release.
• Update the incident register with all communications sent and received.

Phase 6 — Review

• Conduct a Post-Incident Review (PIR) within 5 business days of incident resolution for P1 and P2 incidents; within 10 business days for P3.
• The PIR is blameless and focuses on systems and processes, not individuals.
• Produce a PIR report and raise corrective actions in the NC/CA register for each identified improvement.
• Present PIR findings at the next Management Review; ensure lessons learned feed into control updates.

5. Evidence Preservation Checklist

Proper evidence preservation is critical for forensic investigation, legal proceedings, and regulatory compliance. The Incident Lead is responsible for ensuring evidence is collected and protected.

• Preserve system logs before they are overwritten — collect from SIEM and from individual systems
• Photograph the screens of affected systems before any interaction or shutdown
• Capture a memory dump from affected live systems if technically feasible and safe to do so
• Document the chain of custody for every piece of evidence: who collected it, when, where it was transferred, and who has access
• Store forensic copies in a write-protected or read-only location (e.g., write-protected drive, forensic image with hash verification)
• Do not run antivirus scans or remediation tools on forensic copies — run these on live systems only
• Record all hash values (SHA-256) for forensic images at the time of collection
• Do not conduct investigation or analysis on the original evidence — always work from copies
• Preserve email headers and full raw email content for phishing investigations
• Retain all evidence for a minimum of 12 months or until legal / regulatory proceedings are concluded, whichever is longer

6. Post-Incident Review Template

7. Regulatory Notification Requirements

8. Incident Register Fields

The Incident Register is maintained by the ISM and retained for a minimum of 3 years.

9. Review History