Building an Incident Response Plan from Scratch

A cyberattack doesn’t announce itself. One morning, an alert fires, someone opens a ticket, and by the time leadership is looped in, the damage is already spreading. What separates companies that contain a breach in hours from those stuck in recovery for months isn’t better technology. It’s preparation. Specifically: whether there was a plan before anything went wrong.

An incident response plan (IRP) is a documented, tested procedure for detecting, containing, and recovering from security incidents. Sounds bureaucratic. In practice, it’s the difference between a controlled response and organized chaos at 2 AM.

What Actually Counts as an Incident

Not every alert is an incident. A failed login is noise. Ransomware encrypting a file server is not. The distinction matters because it determines who gets involved and how fast.

Common categories worth defining before anything happens:

• Data breach: unauthorized access to sensitive or regulated data
• Malware infection: ransomware, spyware, wipers, trojans
• Denial of service: attacks degrading or taking down systems
• Insider threat: malicious or accidental actions by staff or contractors
• Supply chain compromise: attacks entering through vendor software (SolarWinds being the textbook case)
• Unauthorized access: credential theft, privilege escalation, lateral movement

A phishing email that was clicked but dropped nothing is different from one that installed a Cobalt Strike beacon. The plan needs to handle both, and tell the team which is which, fast.

Why Most Plans Don’t Actually Work

Plenty of organizations have an incident response document. Far fewer have one anyone has read. And fewer still have tested it against something resembling a real scenario.

The usual problems: the document is three years old, it lists contacts for people who left the company, it assumes tools that were replaced, and nobody on the actual response team has ever seen it. Turns out there’s a meaningful gap between having a policy document and having an operational playbook. One satisfies auditors. The other is what you use when production is down at 3 AM, and nobody knows who’s authorized to pull a compromised server offline.

The Six Phases and What They Mean in Practice

The NIST SP 800-61 framework breaks incident response into six phases. SANS uses similar logic with different names. Either way, the structure holds.

Preparation

Everything before an incident. This is where the real work happens: defining what an incident is, building and training the response team, setting up logging and alerting infrastructure, running tabletop exercises. One detail that gets skipped constantly: pre-authorizing actions. During an active incident, waiting for legal sign-off to isolate a server costs time you don’t have. Decide in advance what can be done immediately, and by whom, without escalation.

Identification

Something happened. The question is what, exactly. This phase is about turning alerts into confirmed incidents, correlating signals across SIEM and EDR tools, determining scope, and building a timeline. Speed here is directly tied to logging quality set up during preparation. Garbage logs mean slow identification. Slow identification means fewer options.

Containment

Short-term containment is fast and blunt: isolate infected hosts, block attacker IPs, disable compromised accounts. Long-term containment is more surgical: temporary fixes, reconfigured systems, enhanced monitoring on specific behaviors. One decision that comes up constantly: disconnect immediately or watch the attacker first? Disconnecting limits damage. Monitoring reveals the full scope. There’s a genuine case for both. This call should be discussed in advance, not improvised under pressure.

Eradication

Remove the threat completely. Patch what was exploited, delete malware and persistence mechanisms, rotate credentials, rebuild compromised systems from clean images. Skipping this step or rushing it is how organizations get re-compromised through the same vector two weeks later. It happens more often than anyone publishes.

Recovery

Restore services in priority order. Validate systems are clean before reconnecting them. Monitor closely for anything recurring. And handle notification obligations – GDPR gives 72 hours to notify supervisory authorities after a personal data breach. That clock doesn’t pause because recovery is still in progress.

Lessons Learned

The phase most teams skip because they’re exhausted. Which is exactly why it matters. A post-incident review should happen within two weeks: what happened, what worked, what didn’t, what gaps were exposed, what changes get made, and by when. Document it. Update the plan. Then actually implement the changes; otherwise, it was just a meeting.

Tools That Make a Plan Executable

The IRP describes what to do. Tools are what make it happen at speed under pressure.

• SIEM: Splunk, Microsoft Sentinel, IBM QRadar for log correlation at scale
• EDR: CrowdStrike Falcon, SentinelOne, Microsoft Defender for behavioral detection and endpoint isolation
• SOAR: Palo Alto XSOAR, Splunk SOAR for automated playbook execution
• Threat intelligence: MISP, Recorded Future for context on attacker TTPs
• Forensics: Velociraptor, Magnet AXIOM, Volatility for investigation and evidence preservation

The tooling matters less than whether people know how to use it under pressure. A Splunk instance with 400 dashboards and no runbooks helps nobody.

Regulatory Alignment Worth Knowing

Depending on industry and geography, an IRP isn’t optional – it’s a legal requirement. Key frameworks:

• NIST SP 800-61 Rev. 2: the baseline for US federal and most enterprise environments
• ISO/IEC 27035: international standard for incident management
• GDPR Article 33: 72-hour breach notification for EU personal data
• NIS2 Directive: incident reporting requirements for essential services operators across the EU
• DORA: EU financial sector resilience requirements in effect since January 2025, with explicit IR testing mandates
• PCI DSS v4.0: payment sector documentation and annual testing requirements

NIS2 and DORA are the ones catching organizations off guard right now. Both significantly raise the bar on documentation, testing frequency, and reporting timelines.

Providers Worth Considering

Some organizations build IR capability entirely in-house. Most don’t have the staff or experience depth to do it well, especially for simulation and testing. A short list:

DXC Technology covers end-to-end IR program development: plan design, tabletop exercises, and managed detection and response. Particularly strong in regulated sectors (energy, healthcare, financial services), including energy software solutions, where compliance alignment is built into the engagement from the start.

Secureworks (Atlanta) offers IR retainer services alongside their Taegis XDR platform. Their Counter Threat Unit publishes ongoing threat intelligence that feeds directly into playbook updates, useful for teams that want detection and response in one environment.

WithSecure (Helsinki) takes a consultative approach to IR program development, with strong alignment to European regulatory requirements. Better fit for organizations building IR capability for the first time than for those looking for a pure managed service.

Trustwave (Chicago) combines managed security services with IR consulting through SpiderLabs, an in-house red team that has produced some of the more detailed industry threat reports over the past decade.

Orange Cyberdefense (France) handles cross-border IR coordination across multiple EU jurisdictions simultaneously. Useful for multinationals managing NIS2 and GDPR obligations in parallel across different countries.

The Mistakes That Show Up Every Time

Even well-prepared teams make predictable errors. The ones that recur most:

• Not testing the plan: a document that’s never been run under simulated pressure is guesswork
• No defined communication protocols: who talks to the press, who calls the regulator, who notifies customers
• Assuming backups are clean without verifying them
• Leaving out third parties: cloud providers, SaaS vendors, MSPs need to be in the process, not notified after the fact
• Treating IR as an IT-only function: legal, communications, HR, and leadership all have roles in a serious incident

And the biggest one: treating the plan as a one-time project. Threats change. Systems change. People leave. An IRP that isn’t actively maintained is outdated before it’s needed.

Frequently Asked Questions

How long does it take to build a functional IRP from scratch?

A basic plan can be drafted in four to six weeks. A mature program with playbooks, tested exercises, and tool integrations realistically takes three to six months.

How often should it be tested?

Annually at minimum. DORA and most enterprise frameworks now push for tabletop exercises twice a year, with full simulations at least once. After any major incident or significant system change, review immediately.

What’s the difference between a tabletop and a red team exercise?

A tabletop is discussion-based; scenarios are walked through, no systems touched. A red team engagement actively simulates attacker techniques against real infrastructure. Both are valuable and test different things.

What’s the first action when an incident is confirmed?

Activate the response team, document time and initial indicators, and begin pre-authorized containment actions. Don’t touch infected systems for cleanup before forensic evidence is preserved; that information is what reveals the full scope of what happened.

• About
• Latest Posts

Milena Baghdasaryan

Content Specialist at PowerDMARC

Milena is a skilled writer and content creator with 7+ years of experience in crafting engaging content on IT, cybersecurity, virtual events, and more. She has a proven track record of delivering high-quality work for international magazines and is a graduate of prestigious institutions such as New York University Abu Dhabi, UWC China, and the College of Europe.

Latest posts by Milena Baghdasaryan (see all)

• Building an Incident Response Plan from Scratch - September 8, 2026
• The New Way Hackers Are Tricking Financial AI Assistants - September 7, 2026
• DNS Security Best Practices: A Complete Hardening Checklist - September 7, 2026