Incident response plan: what it is and what auditors check

The phases of incident response

Most plans follow a standard set of phases. Detection and triage: identify that something happened and assess severity. Containment: stop the incident from spreading. Investigation: determine what happened, when and how. Recovery: restore normal operations. Post-incident review: document lessons learned and update controls.

The plan should define who does what in each phase, how they communicate (especially if normal channels are compromised), and what triggers escalation to leadership, legal or regulators.

What auditors look for

Auditors check that the plan exists, that it is current, that it has been tested, and that actual incidents were handled according to it. They also check that the plan covers regulatory notification requirements.

• A documented, approved incident response plan
• Defined roles and responsibilities
• Communication and escalation procedures
• At least one tabletop exercise per year, with records
• Logs from actual incidents handled under the plan
• Post-incident reviews with lessons learned
• Regulatory notification timelines (HIPAA: 60 days, GDPR: 72 hours)

Tracking incident response in Certifyi

In Certifyi, incident response is a control with the plan, test records and incident logs as evidence. When an incident occurs, the incident record links to the controls that were tested and the findings from the post-incident review.

• Compliance software: incident response evidence beside your other controls.
• CAPA: corrective actions from incident findings.
• Audit management: auditors verify incident response during the audit.

Related terms

CAPA

Corrective and preventive action: the plan, owner and due date attached to an audit finding or incident, tracked until the fix is confirmed and the cause addressed.

Penetration test

An authorised, simulated attack on systems to find weaknesses an attacker could exploit. Most frameworks expect one at least once a year and after significant changes.

Risk register

The list of identified risks with an owner, likelihood, impact, treatment and review date, linked to the controls that treat each one. Usually the first document an auditor asks to see.

Evidence

Any record that shows a control operated: a configuration export, a ticket, a signed policy, an access review. Auditors sample evidence across the period they are reporting on.