Every major compliance framework — SOC 2 (CC7.3–CC7.5), ISO 27001 (A.5.24–A.5.28), HIPAA (§164.308(a)(6)), GDPR (Articles 33–34), and PCI DSS (Requirement 12.10) — requires a documented and tested Incident Response (IR) Plan. Auditors do not just check that the plan exists; they verify that it has been tested, that staff know their roles, and that past incidents were handled according to the process.

IR Plan Structure

Phase 1: Preparation

  • Define the IR team: Incident Commander, technical lead, legal/privacy counsel, communications lead, executive sponsor.
  • Maintain an up-to-date contact list (including out-of-hours contacts) for all IR team members and key vendors.
  • Deploy logging, alerting, and SIEM tooling before an incident occurs.
  • Establish a secure out-of-band communication channel (IR team members should not assume email is secure during an incident).
  • Run tabletop exercises at least annually to test team readiness.

Phase 2: Detection and Analysis

  • Classify alerts into incident severity levels (P1–P4 or Critical/High/Medium/Low) with defined response SLAs.
  • Log incident details immediately: timestamp, detection source, initial scope assessment, affected systems.
  • Determine whether the incident involves personal data — if so, trigger the privacy breach assessment process (72-hour GDPR clock starts when you become "aware").
  • Assign an Incident Ticket in your ITSM or incident log. Every action taken should be timestamped and recorded.

Phase 3: Containment

  • Short-term containment: Isolate affected systems (network segment, disable accounts, block IP ranges) without destroying forensic evidence.
  • Long-term containment: Apply temporary fixes to allow business to continue while full remediation is prepared.
  • Preserve forensic evidence: memory dumps, log exports, disk images where appropriate.

Phase 4: Eradication

  • Identify root cause: vulnerability exploited, phishing credential compromise, misconfiguration.
  • Remove malware, close attack vectors, revoke compromised credentials.
  • Apply patches and update firewall rules/WAF signatures.
  • Verify eradication with a security scan before proceeding to recovery.

Phase 5: Recovery

  • Restore systems from clean backups, or rebuild from infrastructure-as-code where available.
  • Reintroduce systems to production in a controlled, monitored manner.
  • Monitor closely for 24–72 hours post-recovery for signs of re-compromise.
  • Notify affected customers, partners, or regulators as required by law (GDPR: 72 hours; HIPAA Breach Rule: 60 days; US state laws vary).

Phase 6: Lessons Learned

  • Hold a post-incident review within 2 weeks of closure.
  • Document root cause, timeline, actions taken, and recommendations.
  • Update the IR plan, runbooks, and detection rules based on findings.
  • Report findings to executive leadership and, where required, the board.

Evidence for Auditors

  • Signed and dated IR Plan document.
  • Tabletop exercise records (date, attendees, scenario, outcomes).
  • Incident register showing all incidents, severity, response actions, and closure dates.
  • Post-incident review reports for significant incidents during the audit period.
  • Notification records for any breaches reported to regulators or data subjects.