The moment you realize your site has been hacked is not the moment to figure out what to do. The mental space you have during a crisis is limited. Decisions made in the middle of an incident under stress are often worse than decisions made calmly in advance.
An incident response plan is the document that tells you what to do when something goes wrong. Written when things are calm. Followed when things are not. Sites with response plans handle incidents faster and with less damage than sites without them.
This piece covers what an incident response plan includes, how to write one for your situation, and how to actually use it when an incident happens.
Why You Need a Plan Before You Need It
The case for advance planning is clear.
Crisis Mode Is Not Decision-Making Mode
During an active incident, you have less mental capacity for decisions. You are stressed. You are trying to stop the damage. You are dealing with customers and stakeholders.
Decisions about who to call, what to disable, what to communicate need to be made before the crisis, not during it.
Time Matters
The first hour of an incident often determines how bad it gets. Fast response limits damage. Slow response lets it compound.
A plan lets you move fast. Without a plan, you waste time figuring out the basics.
Multiple People Need to Coordinate
If your business has more than one person, incidents involve multiple people. Who does what? Who decides? Who communicates? Without a plan, coordination becomes confused.
Plans Reduce Mistakes
In a panic, people sometimes make things worse. Turning off the wrong server. Notifying customers prematurely. Destroying evidence during cleanup. A plan prevents these mistakes.
Documentation Matters After
After an incident, you may need to document what happened for various stakeholders. Insurance. Regulators. Customers. Lawyers. Having a plan that was followed creates the documentation naturally.
What an Incident Response Plan Contains
A useful plan covers several areas.
Roles & Contacts
Who does what during an incident. Each role and the person in that role. Backup contacts in case the primary is unavailable.
Roles to include:
Incident lead (overall decision maker).
Technical lead (handles the technical response).
Communications lead (handles customer and stakeholder communication).
Legal contact (consult on legal implications).
External contacts (hosting support, security service, lawyer).
Detection & Triage
How you find out about incidents. What sources of alerts to monitor. How to evaluate the severity.
Different incidents need different responses. A minor compromise of a single account needs different handling than a full server compromise.
Containment Steps
What to do immediately to limit damage. Often this includes:
Change critical passwords.
Disable affected accounts.
Take the site offline if needed.
Block attacking IP addresses.
Disable specific compromised features.
The containment steps depend on what type of incident.
Investigation Procedures
How to figure out what happened. What logs to check. What tools to use. What questions to answer:
How did the attacker get in?
What did they access?
What did they change?
When did this start?
Are they still active?
Recovery Procedures
How to restore normal operations. Cleaning malware. Restoring from backup. Verifying the cleanup. Re-enabling features.
Communication Plans
What to tell customers, employees, partners, and others. When to communicate. How to communicate.
Different audiences need different information at different times.
Documentation Requirements
What records to keep about the incident. Timeline of events. Decisions made and why. Actions taken. This documentation is essential for various purposes after.
Post-Incident Review
After the immediate response, what to do to learn from the incident. What went well. What did not. What to change going forward.
Writing Your Plan
The process of creating the plan matters.
Start Simple
A simple plan that exists is much better than an elaborate plan that you never finish writing. Start with the basics. Improve over time.
Write It Now
The plan is useless if it does not exist when you need it. Block time to write it. A few hours produces a usable starting plan.
Make It Specific to Your Site
Generic incident response plans are less useful than ones written for your specific situation. Your hosting provider. Your tools. Your team. Your customers.
The more specific the better.
Include Real Contact Information
Names, phone numbers, email addresses. Account numbers for your hosting provider. Login URLs. The information you would need at 3 AM in a crisis.
Test the Plan
A plan you have never tested is unproven. Periodic tabletop exercises (walking through hypothetical scenarios) reveal gaps and clarify steps.
For larger organizations, full incident simulations are valuable.
Update Regularly
Plans get out of date. People change roles. Contact information changes. Tools change. Procedures change.
Quarterly review keeps the plan current.
Using the Plan During an Incident
The execution matters as much as the writing.
Recognize the Incident
The first step is recognizing that something is wrong. Alerts, customer reports, your own observations.
Many incidents are subtle. Trust unusual signs. Investigate concerns even when you are not sure.
Activate the Plan
When an incident is confirmed (or strongly suspected), activate the response plan. Pull out the document. Start following the steps.
The plan should be where you can access it during an incident. Not just on the affected server (which might be compromised). Somewhere accessible from multiple devices and locations.
Communicate Among Responders
The incident lead should establish a communication channel for the response team. Slack, Zoom, conference call. Everyone working on the response should know how to reach each other.
Document as You Go
The investigation is more valuable if you document what you find as you go. Timeline of events. Actions taken. Decisions made.
Notes during the incident are better than reconstructed notes afterward.
Follow the Steps in Order
The order of incident response steps matters. Containment first. Then investigation. Then recovery. Then communication.
Jumping to communication before containment can make things worse.
Stay Calm
The plan exists so you do not have to figure things out under stress. Follow the plan. Trust the process. Avoid panic decisions.
Specific Incident Scenarios
Different incidents call for different responses.
Site Defacement
Take the site offline. Document the defacement. Investigate how it happened. Clean up. Restore from backup if needed. Improve defenses to prevent recurrence.
Malware Infection
Scan thoroughly. Identify all affected files. Remove malware. Look for backdoors. Restore from clean backup. Update all software. Change all credentials.
Data Breach
Determine what data was accessed. Determine when. Assess regulatory requirements. Plan notifications. Coordinate with legal counsel. Strengthen defenses.
The next piece in this series covers disaster recovery in more detail.
Account Compromise
Identify which accounts. Change passwords. Force logout of all sessions. Audit what the compromised account did. Review for backdoor accounts. Implement stronger authentication.
DDoS Attack
Activate DDoS protection if not already on. Contact hosting provider. Monitor for return. Investigate motivation if possible.
The earlier piece in this series covered DDoS protection.
Phishing Through Your Site
Remove phishing content. Find how it got there. Clean backdoors. Update software. Request blacklist removal. Notify affected parties if needed.
After the Incident
The work continues after immediate resolution.
Post-Incident Review
Schedule a review meeting. Look at what happened from start to end. What worked. What did not. What needs to change.
Document the lessons.
Implement Improvements
Apply the lessons. Strengthen weak defenses. Improve monitoring. Update the response plan. Train people on changes.
Communicate With Stakeholders
The communications during the incident may need follow-up after resolution. Tell customers what was done. Show that lessons were learned. Rebuild trust.
Update the Plan
The plan probably needs updates based on what you learned. New scenarios that came up. Steps that did not work as expected. Information that was missing.
Common Incident Response Mistakes
People stumble in predictable ways.
Not Having a Plan
The biggest mistake. Sites without plans handle incidents worse than sites with them.
Plan That Is Too Detailed
Very detailed plans become hard to follow. The plan should be detailed enough to be useful but readable enough to actually use.
Plan That Is Too Vague
The opposite mistake. A plan that says “respond to the incident” is not useful. Specific steps are what help.
Plan That Is Out of Date
Names of people who no longer work there. Contact information that is wrong. Tools that are no longer used. Outdated plans cause problems during use.
Not Testing the Plan
A plan that has never been tested probably has gaps you do not know about. Test it before you need it.
Skipping Communication
Some site owners focus on technical response and forget about communication. Customers wondering what is happening get angry. Communicate even when you have limited information.
Hiding the Incident
Trying to handle incidents quietly without acknowledging them to customers often makes things worse when customers find out later. Honest communication usually builds trust rather than damaging it.
Closing Thoughts on Crisis Preparation
Incident response planning is one of those activities that pays off only when you need it, which makes it easy to defer. But sites that need a plan and do not have one make significantly worse decisions than sites with plans.
For most sites, the right approach is to write a basic plan now and improve it over time. The first version does not need to be perfect. It just needs to exist.
The plan should be specific to your situation. Generic plans help less than plans written for your specific tools, team, and customers.
Test the plan periodically. Tabletop exercises reveal gaps. Real-world incidents (when they happen) reveal more gaps. Each iteration improves the plan.
Sites with good incident response plans recover from incidents faster and with less damage than sites without them. The difference is the difference between contained incidents and catastrophes.
If you do not have an incident response plan, today is the day to start one. Block an hour. Write down the basics. Add details over time. The plan you write now is the plan you will be glad to have when something happens. The cost of preparation is small. The cost of handling an incident without a plan is large. The trade-off favors preparation overwhelmingly. Make the plan, keep it current, and hope you never need it. If you do need it, you will be grateful you took the time to write it.
