Incident Response Plan
An incident response plan is the pre-agreed playbook for security incidents: how they’re detected, who triages, what severities mean, who communicates what to whom, and how the organization learns afterward. Every framework requires one; the differences are in the clocks — HIPAA’s breach notifications, GDPR’s 72-hour supervisory window, MAS’s one-hour severe-incident notice.
The parts that matter under pressure
Severity definitions with examples (what’s a SEV-1 here); an on-call or escalation path with names, not roles-nobody-holds; containment authority — who may take production down without a meeting; communication templates for customers, regulators, and internally; and the evidence habit: timestamps, decisions, and actions logged as they happen.
What auditors actually test
Not the plan’s prose — its operation. They sample real incidents against the plan: was severity assigned, were the steps followed, does a post-mortem exist with tracked remediations? No incidents in the window? Then they look for the tabletop exercise record. A plan with neither incidents nor exercises is a plan that exists only as a PDF, and auditors score it that way.
The cheapest strong signal
One tabletop a year — two hours, a realistic scenario, notes on what broke in the process, and fixes tracked to closure. It satisfies the audit question, and it’s the difference between a plan and a rehearsed one when the real SEV-1 arrives.
Penetration Test vs Vulnerability Scan — A vulnerability scan is automated and finds known issues; a penetration test is a human actively exploiting your defenses. Auditors and customers ask for both.
Risk Register — A risk register is the living record of identified risks, their scores, owners, and treatments — sampled in every SOC 2 and ISO 27001 audit.