Incident Response Plan: The Template Most Companies Get Wrong

If you are looking for an incident response plan template, stop for a moment. I have seen dozens of incident response plans in Italian SMEs, and most share the same fatal flaw: they are documents written for compliance, not for use during a real incident. An IRP that no one has ever tested is just paper.

Where most plans fail

First mistake: vague roles and responsibilities. "The IT team will manage the incident" is not a plan. Who decides if it is an incident? Who communicates to management? Who talks to legal? Who handles external communications? Every role must have a name (and a backup), not a generic function. Second mistake: no escalation procedures with defined timeframes. If after 30 minutes you have not contained the incident, what happens? Who gets involved? At what point do you call an external incident response provider?

A framework that works

I use a 6-phase approach based on NIST SP 800-61: Preparation (tools, contacts, procedures ready), Identification (how you recognize an incident and classify it by severity), Containment (immediate actions to limit damage), Eradication (remove the cause), Recovery (restore services), Lessons Learned (post-mortem within 72 hours). Each phase has specific checklists, not generic ones.

The most underestimated phase is Preparation. With Presidio, I automated part of the process: SOAR playbooks handle initial triage, automatic case creation in DFIR-IRIS, enrichment with threat intelligence. But automation does not replace human preparation - it replaces repetitive tasks to give the team more time for critical decisions.

The ultimate test: run a tabletop exercise. Simulate ransomware at 2 AM on a Friday. Does everyone know what to do? Does everyone have access to the necessary tools? Are phone numbers up to date? If the answer to any of these questions is no, your plan needs work. If you need consulting to build or test your incident response plan, I am available for a conversation.