Incident Response Plan Template for vCISOs (+ How to Use It)

An incident response plan (IRP) is a documented, step-by-step playbook for detecting, containing, eradicating, and recovering from cybersecurity incidents. For vCISOs, the IRP is one of the most critical deliverables in any engagement — it is the document that gets pulled up at 2 AM when something goes wrong. This guide covers the structure, NIST-aligned phases, and practical advice for building IRPs that actually work when clients need them.

What are the NIST incident response phases?

The NIST SP 800-61 framework defines six phases that form the backbone of any effective IRP. Every section of your template should map to one of these phases:

1. Preparation. This is everything that happens before an incident occurs. It includes building the response team, defining roles, deploying detection tools, establishing communication channels, and training staff. Preparation is where 80% of the work happens — and where most plans fall short.
2. Detection and Analysis. How do you identify that an incident is occurring? Define the data sources (SIEM alerts, endpoint detection, user reports, vendor notifications), triage criteria, and initial analysis steps. Include a severity classification matrix so the team knows the difference between a P1 and a P3.
3. Containment. Once confirmed, how do you stop the incident from spreading? Define short-term containment (isolate affected systems, block malicious IPs, disable compromised accounts) and long-term containment (apply temporary fixes while maintaining business operations). Document decision authority: who can authorize taking a production system offline?
4. Eradication. Remove the root cause. This may involve removing malware, closing exploited vulnerabilities, resetting credentials, or rebuilding compromised systems. The eradication phase should reference the organization's risk register to ensure the underlying vulnerability is tracked for permanent remediation.
5. Recovery. Restore affected systems to normal operation. Define the verification steps before bringing systems back online: integrity checks, monitoring for re-infection, and stakeholder sign-off. Include rollback procedures in case recovery introduces new issues.
6. Post-Incident Activity. The lessons-learned review. Conduct a blameless post-mortem within 5 business days of incident closure. Document what happened, what worked, what did not, and what changes are needed. Update the IRP, risk register, and detection rules based on findings.

What sections should an IRP template include?

A production-ready IRP template needs more than just the NIST phases. Here is the complete section list:

• Document control. Version number, last review date, owner, approval authority. IRPs should be reviewed and updated at least annually or after every significant incident.
• Purpose and scope. What types of incidents does this plan cover? Define the boundary: security incidents, data breaches, availability events, insider threats. Be explicit about what is out of scope (e.g., physical security incidents handled by a separate plan).
• Roles and responsibilities. Define the incident response team: Incident Commander, Technical Lead, Communications Lead, Legal Liaison, Executive Sponsor. For vCISO clients, clarify which roles you fill and which are filled by internal staff.
• Severity classification matrix. A 4-level severity scale (P1 Critical, P2 High, P3 Medium, P4 Low) with clear criteria for each level based on data sensitivity, system criticality, number of users affected, and regulatory implications.
• Escalation procedures. Who gets notified at each severity level, how quickly, and through which channel. Include after-hours contact procedures. For vCISO engagements, this should specify when to contact the vCISO versus handling internally.
• Communication templates. Pre-drafted templates for internal notifications, executive updates, customer notifications, regulatory disclosures, and media statements. Having these ready before an incident saves critical hours during a crisis.
• Phase-by-phase procedures. Detailed playbooks for each NIST phase as outlined above.
• Regulatory notification requirements. A matrix of applicable regulations with notification timelines: GDPR (72 hours to supervisory authority), SEC (4 business days for material incidents), state breach notification laws, contractual obligations to clients and partners.
• Evidence preservation. Chain of custody procedures, forensic imaging requirements, log retention policies. Document what must be preserved for potential legal proceedings or regulatory investigations.
• External resources. Contact information for external counsel, forensics firms, cyber insurance provider, law enforcement (FBI IC3, local authorities), and PR/communications support.

How do you customize an IRP for each client?

A template is a starting point, not a finished product. The sections that require the most client-specific customization are:

• Severity matrix. A P1 for a healthcare provider (patient data exposed) looks different from a P1 for a SaaS company (production outage). Calibrate severity levels to the client's specific data types, systems, and risk tolerance.
• Escalation paths. Map the actual people — by name, phone number, and backup contact — not just roles. Update this section whenever there is a personnel change. Stale contact lists are the most common IRP failure point.
• Regulatory requirements. Determine which regulations apply based on the client's industry, geography, and data types. A company processing EU personal data has GDPR obligations. A publicly traded company has SEC disclosure requirements. A healthcare organization has HIPAA breach notification rules.
• Technology environment. Reference the client's specific tools: their SIEM, EDR solution, backup systems, and cloud providers. Generic instructions like "check the SIEM" are useless if the team does not know which SIEM or how to query it.
• Third-party dependencies. If the client relies on a managed security provider (MSSP) for detection and response, define the handoff points. Who does initial triage? When does the MSSP escalate to the vCISO?

How should you test an incident response plan?

An untested IRP is an assumption. There are three levels of testing, and every vCISO engagement should include at least the first:

1. Tabletop exercise. A facilitated discussion where the response team walks through a hypothetical scenario step by step. No systems are touched — the goal is to identify gaps in the plan, unclear roles, and missing procedures. Run these annually at minimum, and after any significant organizational change.
2. Functional exercise. A simulated incident where the team performs actual response activities (without affecting production). This tests technical procedures: can the team actually isolate a system, capture forensic images, and execute the communication plan?
3. Full-scale exercise. A realistic simulation that engages all stakeholders including executives, legal, and communications. These are resource-intensive and typically reserved for mature programs or regulatory requirements.

Document the results of every exercise. Findings should feed into risk register updates and IRP revisions. Many compliance frameworks — including SOC 2 — require evidence of regular IRP testing.

What are common IRP mistakes vCISOs should avoid?

• Writing a plan nobody has read. If the incident response team has never seen the IRP before an incident, it is useless. Distribute the plan, walk through it during onboarding, and review it in tabletop exercises.
• Missing the first 60 minutes. The first hour after detection is the most critical. If your plan does not have clear, step-by-step instructions for the first 60 minutes — who to call, what to preserve, what to isolate — the team will make ad-hoc decisions under pressure.
• No communication plan. Technical response is only half the equation. Who notifies the CEO? Who handles customer communications? Who contacts the cyber insurance provider? These decisions should not be made during a crisis.
• Ignoring regulatory timelines. GDPR's 72-hour notification window starts when the organization becomes "aware" of a breach. If your IRP does not include a process for making the awareness determination and triggering the notification workflow, you risk compliance violations on top of the incident itself.

How does an IRP connect to the broader security program?

The IRP does not exist in isolation. It connects to several other artifacts in a well-structured vCISO practice:

• Risk register. Incidents may trigger new risks or change the severity of existing ones. Post-incident findings should update the risk register.
• Policies. The IRP should reference (not duplicate) related policies: acceptable use, data classification, access control. Policy violations often surface during incident investigation.
• Board reporting. Incident metrics (count, severity, response time, lessons learned) belong in board reports. Boards want to know the organization can respond effectively, not just prevent incidents.
• Compliance evidence. IRP documentation, testing records, and post-incident reports are audit evidence for SOC 2, ISO 27001, and other frameworks.