Creating an Incident Response Plan: What to Do When You're Hacked
Key Takeaways
A response plan turns a frightening, fast-moving security incident into a sequence of decisions people can carry out. The work is mostly preparation: knowing who acts, what matters most, and how to recover safely.
Define scope, severity levels, and decision-making authority before an incident occurs.
Keep current inventories of critical systems, data, backups, and response contacts.
Preserve evidence while containing compromised devices, accounts, and access paths.
Restore from verified backups only after the threat is understood and contained.
Review the response afterward and revise the plan through realistic exercises.
Define your incident response plan before an attack
A useful incident response plan gives people a shared way to act when normal routines break down. It should fit the organization’s size and obligations, not simply borrow a template and leave it untouched. Clear roles, contact paths, and recovery priorities reduce delay when facts are incomplete. For a broader overview of what a plan covers, see this incident response plan guide.
Set the plan’s scope, objectives, and severity levels
Start by deciding which people, systems, locations, and data the plan covers. State what the response is meant to achieve: protect people, limit harm, preserve evidence, restore essential operations, and meet applicable obligations. Severity levels help the incident lead bring in the right expertise without treating every alert as a crisis. For organizations connected to financial networks, the wider consequences of disruption can also matter; financial-system resilience is one reason to consider dependencies beyond the company boundary.
A small set of levels can make decisions easier to communicate. The labels matter less than having shared criteria and clear actions attached to each one.
Severity | Example signal | Initial response |
|---|---|---|
Low | A suspicious message reported with no sign of access | Review the report and check for related activity |
Moderate | One account shows unusual access or changes | Notify the incident lead and investigate the account |
High | Several systems show compromise or business disruption | Activate the response team and begin containment |
Critical | Sensitive data exposure or major operational impact is suspected | Escalate to leadership and legal advisers promptly |
These are starting points, not universal thresholds. Adapt them to your systems and risk tolerance, then make sure staff know who can change a severity rating as new evidence emerges.
Assign an incident lead and clarify team responsibilities
Choose an incident lead who can coordinate decisions, bring specialists together, and keep the response moving. That person does not need to perform every technical task; in fact, separating coordination from hands-on investigation often makes the work clearer. Identify backups for key roles, since an incident may happen outside normal hours or affect the people who usually respond.
Spell out who can isolate equipment, disable accounts, approve external notices, and authorize recovery steps. Include technical, legal, communications, operations, and executive contacts where relevant. A plan that names responsibilities in advance can prevent two teams from making conflicting changes—or assuming someone else has acted.
List critical systems, data, backups, and external contacts
Build an inventory that reflects how the organization actually works: the systems it depends on, the data those systems hold, and the people or providers who can help restore them. Include backup locations and access procedures, but do not put live passwords or recovery secrets in a broadly shared document. Small and specialized businesses need the same operational clarity; for example, a firm providing exterior cleaning services or running a tuning-file service should know which records and systems keep customer work moving. If equipment relies on a 12V power supply, record that dependency where it belongs in the relevant asset inventory.
Keep the inventory useful rather than exhaustive. Review it when systems, suppliers, data flows, or staff responsibilities change, and make sure the response team can access it during an outage.
Prepare secure communication channels and response tools
A compromised email account or collaboration platform may no longer be trustworthy, so establish an alternate way for the team to coordinate. Test access to that channel in advance, including how people will verify that a message is really from the incident lead. Keep response tools and contact details available without making sensitive credentials easy to discover.
A short preparation list is more practical than a drawer full of untested tools. Confirm that the people responsible can reach the basics:
A separate communication channel for incident coordination.
Current contact details for internal leads and outside specialists.
Procedures for preserving logs and relevant system information.
Secure access to backup instructions and recovery documentation.
Review these items periodically and rehearse using them. Familiarity matters: a channel that nobody has tried is not a dependable fallback.
Detect an incident and activate the response
Detection is rarely a dramatic moment with a clear label attached. An employee may report a strange message, an administrator may notice an unfamiliar login, or a service may stop behaving normally. Treat reports as signals to examine, not proof of a breach or proof that everything is fine. A defined process for deciding who investigates and when the incident lead is called makes those first minutes less chaotic.
Recognize signs of a breach, ransomware, or account takeover
Possible warning signs include unexpected password-reset messages, unfamiliar devices or locations in account activity, new administrator accounts, files that suddenly cannot be opened, and unusual system behavior. A single sign can have an innocent explanation, but several related signals deserve prompt attention. Phishing remains one possible route into an organization; email threat detection practices can help security teams think about how suspicious messages and access attempts are identified and handled.
Employees should know how to report a concern without trying to investigate it themselves. A short, memorable reporting path is more useful than a long policy that few people can find.
Verify suspicious activity without disturbing evidence
Before taking action, record what was observed, when it appeared, and who reported it. Check reliable sources such as authentication records, endpoint alerts, or a second trusted administrator rather than relying on a screenshot alone. Avoid opening suspected attachments, forwarding malicious messages casually, or making changes that could erase useful information.
Verification should be quick enough to support a timely response, but careful enough to avoid turning a small event into a larger one. When the evidence points toward active compromise, escalate rather than waiting for certainty that may never arrive.
Classify the incident and decide when to escalate
Use the severity criteria in the plan to judge likely impact, scope, and urgency. Consider whether sensitive data may be exposed, whether multiple people or systems are affected, and whether essential operations are at risk. The incident lead should be able to raise the level as facts change; an early classification is a working judgment, not a permanent verdict.
Ransomware has its own practical considerations because it can disrupt access to files and services. Reviewing ransomware response basics alongside the organization’s own procedures can help teams prepare for that specific type of disruption. If the impact may involve regulated data or critical services, bring the appropriate leaders and advisers in early.
Start an incident log with timestamps and actions taken
Keep a single incident log that records observations, decisions, actions, responsible people, and timestamps. Use a consistent time zone and note whether a time is approximate. The log helps the team avoid repeating checks, understand why a decision was made, and build a reliable account later for leadership or external reviewers.
A log is useful only if it distinguishes what is known from what is suspected. Keep it factual and limit access to people who need it. This short video placeholder can sit alongside the written plan as a prompt for team training.
Contain the threat and limit further damage
Containment is the effort to stop an attacker or malicious activity from spreading while keeping options open for investigation and recovery. The right move depends on what is affected: a single account, a workstation, a cloud service, or a wider network segment. Fast action matters, but an impulsive shutdown or broad disconnection can disrupt essential work and remove evidence. Follow the plan, communicate changes, and record who authorized them.
Isolate affected devices, accounts, or network segments
If a device appears compromised, disconnect it from the network when doing so is safe and consistent with the response plan. For a cloud service or network segment, limit the affected path without cutting off unrelated operations unnecessarily. An incident lead should coordinate these steps so teams do not make contradictory changes while trying to help.
Isolation is a containment measure, not a diagnosis. Preserve the device or account state where possible, and record the time and method of isolation so investigators can interpret what follows.
Disable compromised credentials and revoke active sessions
When an account is believed to be compromised, disable or restrict it and revoke active sessions according to the organization’s procedures. Check for related accounts or access tokens that could remain usable even after a password changes. Prioritize accounts with administrative privileges or access to important data, while coordinating changes that could interrupt business processes.
Avoid sending reset instructions through a channel that may itself be under the attacker’s control. Confirm the user’s identity through a trusted route, and note which sessions or credentials were invalidated.
Block malicious access while preserving evidence
Security teams may need to block known malicious addresses, domains, or access routes, but they should document the basis for each change. Preserve relevant messages, logs, and indicators before they are deleted or altered, and keep copies in a controlled location. If outside specialists are assisting, agree on what evidence they need and how it will be shared securely.
The aim is to restrict the attacker’s options without obscuring the trail. Keep a record of what was blocked, when, and by whom; that information can help explain both the containment decision and later system behavior.
Avoid shutting down or wiping systems before assessing the impact
Turning off a device or wiping it may destroy volatile information that could help establish what happened. In some situations, shutdown is still the safest choice, especially if active harm is continuing, but that decision should follow an informed assessment rather than reflex. Consult the incident lead or a qualified responder when possible, and preserve evidence before changes are made.
Backups are part of recovery, not a substitute for understanding the event. A separate backup and disaster recovery plan can help teams prepare restoration steps without rushing to overwrite affected systems.
Investigate the breach and remove the attacker
Once immediate spread is under control, the team needs to establish what happened and whether the attacker still has access. The investigation should be proportionate to the incident, documented, and handled by people with suitable authority. Make sure the team can explain its findings and separate confirmed facts from likely explanations. A careful investigation guides safer removal and reduces the chance of restoring the same weakness that enabled the breach.
Determine which systems and data were affected
Map the known activity to accounts, devices, services, and data stores. Check whether the affected systems connect to other environments or rely on shared providers, and ask what information those systems could reach. A breach may extend beyond the first device that raised an alert, so avoid treating that first signal as the full scope.
The team should describe uncertainty plainly. If it cannot yet determine whether data was accessed or copied, record that as unresolved and identify what evidence could answer the question.
Review logs, alerts, and forensic evidence
Bring together relevant authentication logs, endpoint records, network events, cloud activity, user reports, and preserved devices. Keep the original evidence protected and record who collected or handled it. If the incident may lead to legal or regulatory review, consult appropriate advisers about collection and retention practices.
A consistent timeline helps analysts connect events that otherwise look unrelated. Where records are missing or unavailable, note the gap rather than filling it with assumptions.
Identify the entry point and check for persistence
Look for the earliest credible sign of unauthorized access, then trace how access may have expanded. Common avenues to examine include stolen credentials, exposed services, malicious attachments, and unpatched software; the evidence should determine which, if any, applies. Also check for new accounts, scheduled tasks, altered configurations, or other changes that could allow access to continue after the initial route is closed.
Some organizations use authorized security testing to find weaknesses before an attacker does; this overview of ethical attack simulations describes that preventive context. During an active incident, however, investigation should stay within the scope and authority set by the response lead.
Remove malware, unauthorized access, and exposed vulnerabilities
Removal should follow a confident understanding of what has been affected. Eliminate unauthorized accounts or software, close the access route, and address the vulnerability or configuration problem that allowed the activity. If the team cannot verify that a system is clean, rebuilding it from a trusted source may be safer than attempting a piecemeal cleanup.
Record each remediation step and keep monitoring for signs that access remains. When specialist support is needed, share only the information required for the work and use an approved secure channel.
Restore systems and resume operations safely
Recovery is not simply a matter of turning everything back on. Systems should return in a controlled order, with checks that the threat is contained and the data is trustworthy. The organization also needs to decide which services are essential and how to communicate temporary limitations to the people who rely on them. A documented recovery sequence makes those choices easier to manage under pressure.
Confirm the threat is contained before reconnecting systems
Before reconnecting a device or restoring a service, confirm that the known access path has been addressed and that relevant checks are complete. Consider what the system connects to and whether a return to service could spread an unresolved problem. The incident lead should approve the transition and make sure monitoring is ready to detect renewed activity.
If evidence remains uncertain, restore in stages rather than reconnecting the entire environment at once. A cautious sequence can reduce the risk of repeating the disruption.
Restore clean data from verified backups
Choose backups that are believed to predate the compromise and verify that they are intact before using them. Follow documented restoration steps, and test important applications and data before returning them to normal use. Keep a copy of affected data or systems when appropriate for investigation and follow any retention instructions from advisers.
Backups should be protected from the same access paths that affect production systems. Recovery exercises can reveal whether the organization can locate, access, and restore the data when ordinary systems are unavailable.
Reset credentials and strengthen access controls
Reset credentials that may have been exposed, starting with privileged or high-impact accounts. Require stronger authentication where available, review who has administrative access, and remove permissions that are no longer needed. Make changes in a coordinated way so old sessions, recovery methods, or connected services do not leave a route open.
Explain the changes to affected employees through a trusted channel. A secure reset is more likely to succeed when people know what action is expected and how to verify that the request is legitimate.
Monitor restored systems for signs of recurring activity
Keep heightened watch on restored systems and accounts for unusual logins, unexpected configuration changes, or repeat alerts. Define how long enhanced monitoring will continue and who reviews the results. If suspicious activity returns, reopen the incident and revisit containment rather than assuming the original cleanup failed in only one specific way.
Document the monitoring outcome as part of the recovery record. That gives the team a clearer basis for deciding when normal operations can resume.
Coordinate communications and meet reporting obligations
Clear communication supports the response, but careless communication can create confusion or expose sensitive details. Decide who is authorized to speak for the organization and who approves messages to employees, customers, partners, and the public. Keep updates aligned with the known facts, and revise them as the investigation develops. Legal and contractual duties can vary, so seek qualified advice rather than relying on a generic deadline.
Notify employees, leadership, customers, and partners as appropriate
Tell each audience what it needs to know to act safely. Employees may need instructions to reset credentials or report suspicious messages, while customers may need practical information about services or data. Leadership needs a concise view of impact, uncertainty, decisions, and resource needs. Share only details that are relevant to the audience and safe to disclose.
Use an approved channel and give people a clear place to ask questions. If the facts change, correct earlier information promptly rather than allowing speculation to fill the gap.
Contact law enforcement, insurers, or incident response specialists
Depending on the incident, the organization may need help from law enforcement, its insurer, or qualified incident response specialists. Check existing policies and contracts for instructions about whom to contact and what records to retain. Do not wait until evidence has been lost or a deadline is close to find the relevant contact details.
Keep a record of calls, advice received, and decisions made. The incident lead should coordinate external engagement so information is consistent and responsibilities remain clear.
Assess legal, regulatory, and contractual notification requirements
Identify the types of information and services involved, the people affected, and the jurisdictions or agreements that may apply. Bring legal, privacy, and compliance advisers into the assessment early, since notification requirements depend on details that may still be under investigation. Record what is known, what remains uncertain, and the rationale for each decision.
Avoid assuming that one reporting rule applies to every incident. A careful assessment is more useful than a rushed conclusion based on a headline or a checklist written for a different organization.
Keep public statements accurate, timely, and consistent
Prepare statements around confirmed information and avoid promising outcomes that the investigation cannot support. Designate a spokesperson, keep a current version of approved language, and coordinate updates across channels. If a fact is not yet known, say so plainly and explain when the organization expects to provide another update, if that can be stated responsibly.
Consistency does not mean repeating outdated information. Update messages when the evidence changes, and correct material errors directly.
Review the response and improve the plan
The incident is not fully closed when systems are back online. A review helps turn difficult experience into changes that make the next response more effective. Include people who made decisions and people who carried them out, while keeping the discussion focused on evidence and process rather than blame. The best review produces a manageable set of improvements with named owners and due dates.
Document the incident timeline, decisions, and business impact
Assemble the incident log, timeline, major decisions, affected services, and business impact in one review record. Note what the team knew at each decision point, not only what became clear later. This helps explain why actions made sense at the time and identifies where different information or authority might have changed the result.
Keep the record factual and appropriately restricted. It may support future training, audits, or communications, so make it clear enough to understand without relying on individual memory.
Identify gaps in detection, containment, and recovery
Ask where the process slowed down: Was a report difficult to make? Did the team lack access to a log, contact, or backup? Did people disagree about who could authorize isolation or restoration? Look for recurring patterns rather than judging the response by a single imperfect choice.
A gap should lead to an actionable change. Distinguish a missing technical control from a communication or decision-making problem, since each may need a different owner and remedy.
Update procedures, contact lists, and technical safeguards
Revise the plan based on what the review found. Update roles, contact details, severity criteria, recovery instructions, and technical safeguards, then tell the people whose work changes. Keep old copies from being mistaken for the current plan, and track whether improvements have actually been completed.
The author of this article is also the author of the cyber security book Your System's Sweetspots. Treat its title as a starting point for continued reflection, not as a replacement for organization-specific procedures.
Test the incident response plan with realistic exercises
Run exercises that let people practice making decisions with incomplete information. A tabletop discussion can test escalation, communication, and authority; a more technical exercise can test isolation or restoration steps when appropriate. Include people who would have real responsibilities during an incident, and capture what was confusing or unavailable.
Repeat exercises after significant changes to systems or responsibilities. A short, practical test on a regular cadence is more revealing than a polished plan that nobody has tried to use.
Conclusion
A well-maintained incident response plan cannot prevent every breach, but it can make the response more deliberate: detect the problem, contain it carefully, understand its scope, and restore operations with evidence and communication in mind. Keep the plan current, test it with the people who would use it, and explore the book, Your System's Sweetspots, as a further reading option from this article’s author.
Frequently Asked Questions
What is an incident response plan?
It is a documented set of roles, decisions, and procedures that helps an organization identify, assess, respond to, and recover from security incidents.
Who should be on an incident response team?
The team should include an incident lead and the technical, operational, legal, communications, and leadership contacts needed for the organization’s risks. Assign backups for important roles.
What should I do first if I think my organization was hacked?
Report the concern through the established channel, preserve what you observed, and contact the designated incident lead. Avoid making changes that could erase evidence unless immediate safety requires action.
How do you decide how severe an incident is?
Assess the likely scope, sensitivity of affected data, operational impact, and urgency. Use pre-agreed severity criteria, and raise the classification as credible new information emerges.
Should I shut down a device that may be compromised?
Not automatically. Shutting down can disrupt harmful activity, but it may also destroy useful evidence. Follow the response plan and consult the incident lead or a qualified responder where possible.
How often should an incident response plan be tested?
Test it regularly and after significant changes to systems, suppliers, or responsibilities. Exercises should check whether people can reach contacts, make decisions, and carry out recovery steps.
What should an organization review after an incident?
Review the timeline, decisions, business impact, and gaps in detection, containment, communication, and recovery. The author of this article is also the author of the cyber security book Your System's Sweetspots.
Comments