How to Build an Incident Response Plan for Cyber Attacks

You’re sitting at your desk, coffee in hand, when an alert pops up. A user reports that their machine is acting strange. Files are being renamed. A ransom note appears. Your heart sinks. This is the moment every IT professional dreads, but it doesn’t have to be chaos. With a solid incident response plan, you can turn panic into a process.

At PythonSkillset, we’ve seen too many teams scramble when a breach happens. The difference between a contained incident and a full-blown disaster often comes down to preparation. Let’s walk through building a plan that actually works.

Why You Need a Plan

Think of an incident response plan like a fire drill. You don’t wait until the building is burning to figure out where the exits are. The same logic applies to cyber attacks. Without a plan, you waste precious minutes deciding who does what. With a plan, you move fast and smart.

A good plan reduces damage, cuts recovery time, and saves money. According to IBM’s 2023 Cost of a Data Breach report, organizations with an incident response team and tested plan saved an average of $1.5 million compared to those without. That’s real money.

The Six Phases of Incident Response

Most frameworks, like NIST and SANS, break incident response into six phases. Let’s walk through each one.

1. Preparation

This is the most important phase. You can’t respond to what you can’t see. Start by identifying your critical assets. What data would bring your business to a halt if it got encrypted? Customer databases? Financial records? Source code? Make a list.

Next, set up monitoring tools. PythonSkillset recommends using open-source tools like Wazuh for log analysis or OSSEC for host-based intrusion detection. These tools give you visibility into what’s happening on your network.

Also, create a communication tree. Who gets called first? The IT manager? The CEO? Legal? Write down phone numbers and backup contacts. Test this list quarterly. People change jobs, and you don’t want to call someone who left six months ago.

2. Identification

This is where you detect the incident. Not every alert is a real attack. False positives happen. But you need a process to separate the signal from the noise.

Set up thresholds. For example, if a user logs in from three different countries in an hour, that’s suspicious. If a server sends out 10GB of data at 3 AM, that’s worth investigating.

Train your team to recognize common signs: unusual network traffic, unexpected system crashes, strange file modifications, or users reporting slow performance. The faster you identify a real incident, the sooner you can contain it.

3. Containment

Once you confirm an attack, your first job is to stop it from spreading. This is where you make tough decisions. Do you disconnect the affected system from the network? Do you shut down a server? Every second counts.

Short-term containment might mean isolating a compromised machine. Long-term containment could involve applying temporary patches or blocking malicious IP addresses at the firewall. Document every action you take. You’ll need this for the investigation later.

A real-world example: In 2021, a mid-sized healthcare company detected ransomware on a single workstation. Their plan kicked in. They immediately disconnected that machine from the network, then scanned all connected systems. They found the malware hadn’t spread. They restored from backups and were back online in four hours. Without a plan, that same attack could have taken days.

3. Eradication

Once you’ve contained the threat, you need to remove it completely. This means deleting malware, closing backdoors, and patching vulnerabilities. Don’t just clean the infected machine. Check every system that might have been touched.

For example, if an attacker used a phishing email to gain access, you need to reset passwords for all users who might have been compromised. If they exploited a known vulnerability, apply the patch immediately. This phase is about making sure the attacker can’t come back through the same door.

4. Recovery

Now you bring systems back online. But don’t rush. Restore from clean backups. Verify that the malware is gone. Test each system before putting it back into production.

This is also the time to monitor closely. Attackers sometimes leave backdoors for later. Keep your detection tools on high alert for at least a week after recovery. If something looks off, investigate before assuming it’s safe.

5. Lessons Learned

After the dust settles, hold a post-mortem meeting. This isn’t about blaming anyone. It’s about understanding what happened and how to prevent it from happening again.

Ask questions like: - How did the attacker get in? - What controls failed? - What worked well? - What would we do differently next time?

Document everything. Update your plan based on what you learn. This is how you get better.

Building Your Team

You can’t do this alone. Your incident response team needs clear roles. Here’s a simple structure:

• Incident Commander: The person who makes decisions and coordinates the response. This is usually a senior IT manager.
• Technical Lead: Handles the hands-on work—analyzing logs, removing malware, restoring systems.
• Communications Lead: Manages internal and external messaging. This person talks to executives, customers, and possibly the press.
• Legal Counsel: Advises on compliance and liability issues. Not every organization has in-house legal, but you should have a contact ready.

Assign backups for each role. People get sick, go on vacation, or might be the ones affected by the attack.

Creating Your Playbook

A playbook is a step-by-step guide for common scenarios. You don’t need to write a novel. Keep it simple and actionable.

Start with the most likely threats for your organization. For a small business, that might be ransomware and phishing. For a larger company, add DDoS attacks and insider threats.

For each scenario, write down: - Triggers: What signs indicate this attack is happening? - Immediate actions: Who gets notified? What systems get isolated? - Containment steps: How do you stop the spread? - Recovery steps: How do you restore normal operations? - Communication templates: Pre-written emails for notifying employees, customers, or regulators.

Here’s a real example from PythonSkillset’s own playbook for ransomware:

Trigger: User reports files with .encrypted extension. Immediate action: Disconnect the affected machine from the network. Containment: Block the ransomware’s command-and-control IP addresses at the firewall. Recovery: Restore files from the most recent clean backup. Communication: Send an internal email to all staff: “We are investigating a security incident. Do not open any suspicious attachments. IT will provide updates within two hours.”

Testing Your Plan

A plan that sits in a drawer is useless. You need to test it. Run tabletop exercises with your team. Simulate a phishing attack or a ransomware scenario. Walk through each step and see where things break.

For example, during a tabletop exercise at PythonSkillset, we discovered that our backup restoration process took six hours longer than expected. The issue? We hadn’t tested restoring from offsite backups in over a year. We fixed that before a real attack hit.

Schedule these exercises quarterly. Start simple, then add complexity. Throw in a twist like “the incident commander is on vacation” or “the backup server is also compromised.” This builds muscle memory.

Tools You’ll Need

You don’t need expensive enterprise software to start. Here are some practical tools:

• SIEM (Security Information and Event Management): Wazuh is free and powerful. It collects logs from your systems and alerts on suspicious activity.
• Endpoint Detection and Response (EDR): Velociraptor is an open-source tool that helps you hunt for threats on endpoints.
• Backup software: Use something like BorgBackup or Restic. Test your restores regularly.
• Communication platform: Slack or Teams works, but have a backup like SMS or phone calls in case your primary system goes down.

Writing Your Plan

Keep it simple. A 50-page document nobody reads is worse than a one-page checklist that gets used. Here’s what to include:

• Scope: What systems and data are covered? (e.g., all company laptops, servers, cloud services)
• Roles and responsibilities: Who does what? Include names and contact info.
• Detection methods: How will you know an incident is happening? List your monitoring tools and alert thresholds.
• Containment procedures: Step-by-step instructions for isolating affected systems.
• Recovery procedures: How to restore from backups, rebuild servers, and verify integrity.
• Communication plan: Who gets notified and when. Include templates for internal and external messages.
• Post-incident review: A checklist for what to analyze after the dust settles.

Real-World Example: A Phishing Attack

Let’s say an employee clicks a link in a phishing email. The attacker gains access to their email account. Here’s how your plan should handle it:

1. Detection: Your email security tool flags the phishing email. Or the employee reports it.
2. Containment: Immediately disable the compromised account. Force a password reset. Check if the attacker accessed other accounts.
3. Eradication: Scan the employee’s machine for malware. Remove any malicious files. Check email rules for forwarding rules the attacker might have set up.
4. Recovery: Restore any deleted emails from backup. Notify the employee and their manager. Monitor the account for suspicious activity for the next 30 days.
5. Lessons learned: Why did the employee click the link? Was training insufficient? Did the email filter miss it? Fix the root cause.

Testing Makes Perfect

You can’t know if your plan works until you test it. Run a simulated attack. Pick a scenario like a ransomware infection or a data breach. Gather your team in a room (or on a video call) and walk through the steps.

Time each phase. How long did it take to identify the incident? To contain it? To recover? Set targets. For example, aim to contain a ransomware attack within 30 minutes. If you miss that target, figure out why and adjust.

Document every test. Track improvements over time. This isn’t about perfection. It’s about getting better.

Common Mistakes to Avoid

• Not updating the plan: Your plan from two years ago might not cover new threats like supply chain attacks or AI-generated phishing. Review and update it at least annually.
• Ignoring small incidents: A single compromised account might seem minor, but attackers often start small. Treat every incident seriously.
• Forgetting about communication: During a crisis, rumors spread fast. Have a plan for what you tell employees, customers, and the public. Silence creates fear.
• Not testing backups: You’d be surprised how many organizations discover their backups are corrupted only when they need them. Test restores monthly.

Keeping It Alive

An incident response plan isn’t a one-time project. It’s a living document. Review it after every incident, even false alarms. Update it when you add new systems or change vendors. Share it with new team members during onboarding.

At PythonSkillset, we review our plan every six months. We also run a surprise drill once a year. No warning. Just a simulated attack. It’s uncomfortable, but it reveals gaps you didn’t know existed.

Final Thoughts

Building an incident response plan doesn’t have to be overwhelming. Start small. Write down the basics. Test it. Improve it. The goal isn’t perfection—it’s progress.

Remember, the best time to prepare for a cyber attack is before it happens. The second best time is right now. So grab a notebook, gather your team, and start writing. Your future self will thank you.