Incident Response Checklist
This article is a reference resource for IT compliance and security. It is not professional advice. Consult professionals for guidance specific to your situation.
A security incident is happening. Someone reported suspicious activity, a monitoring alert fired, or an employee noticed something wrong. Right now, you need to move quickly but systematically. You need to understand what's happening, contain the damage, investigate what went wrong, and communicate with the people who need to know. The difference between a controlled incident response and a chaotic one is having a framework you've thought through in advance. This article walks you through what you need to evaluate and verify as an incident unfolds, structured as the phases you'll move through from detection to recovery.
The key to effective incident response is that you prepare the framework before you need it. When an actual incident happens, your team is stressed, information is incomplete, and the pressure to act is intense. Having a clear sequence of steps that you've already thought through removes the need to invent process in the middle of a crisis. You're executing a plan, not making it up.
Understanding the Incident Phases and What They Require
Incident response has distinct phases, and each one involves different questions you need to answer and actions you need to take. Understanding the phases helps you know where you are in the process and what needs to happen next.
The detection and assessment phase is about understanding what's actually happening. Has there been unauthorized access? Is data leaving your network? Are systems not responding? Is this real, or is it a false alarm? You're gathering basic facts, not fully investigating yet. This phase answers the question: is this an actual security incident?
The escalation and notification phase happens when you've confirmed an incident is real. This is about getting the right people informed so the organization can respond. You notify your incident response team, your leadership, your legal and compliance teams if necessary, and in some cases external parties like law enforcement or breach notification attorneys. The goal is to make sure the people who need to coordinate the response are in the loop.
The containment phase is about stopping the immediate damage. If an account is compromised, you disable it. If a system is infected, you take it offline. If data is being exfiltrated, you cut the connection. The goal is to stop the active problem. This phase buys you time to investigate without the situation getting worse.
The investigation phase is where you find out what actually happened. How did the attacker get in? What systems did they access? What data did they see or take? What did they do? You're gathering evidence, understanding the scope, and documenting facts. This phase informs everything that comes next.
The communication phase runs parallel to investigation and containment. You communicate with affected parties, with your organization, and with external parties depending on the incident. The goal is to keep visibility on what's happening and set correct expectations about what you know and don't know.
The recovery and restoration phase is about bringing systems back to normal operation. You clean up compromised systems, change credentials, reimage machines, restore from backups, or deploy new infrastructure. You're removing the attacker's footprint and making sure systems are actually clean before bringing them back online.
The post-incident phase happens after immediate response is over. You document what happened, you identify what went wrong in your controls that allowed the incident to happen, and you make changes so it doesn't happen again. This is where incident response turns into organizational learning.
Detection and Initial Assessment
The incident has come to your attention somehow. Someone reported something suspicious, a tool detected unusual activity, or a customer called to report an issue. Your first job is to figure out whether this is actually a security incident or whether it's a false alarm.
Start by understanding where the report came from and what made someone think this was a problem. If someone reported unusual login activity, ask them exactly what they saw. If a tool generated an alert, look at the actual alert and the raw data. Don't accept summaries at this stage; get the specifics.
From there, assess the scope of what you're looking at. Is this one user's account or many accounts? Is it one system or multiple systems? Is it happening now or is it something historical that someone just discovered? The scope tells you how big the problem is and how fast you need to move.
Ask about timing. When did this start? How long has it been happening? Do you have visibility into what happened before someone noticed? If a data exfiltration started three days ago but nobody noticed until today, that matters for investigation.
Try to confirm whether the activity is actually unauthorized. Sometimes what looks like a security issue is a legitimate business action that someone didn't know about. Is this activity something a legitimate user might be doing, or is it clearly unauthorized? Confirming that this is actually a problem rather than a false alarm is important because it determines how quickly you escalate.
Escalation and Notification
Once you've confirmed an incident is real, you need to notify the right people so the organization can coordinate a response. Who you notify and how quickly depends on the severity of the incident and your notification procedures.
Start with your incident response team or whoever your organization has designated to handle security incidents. If you have a security person, they need to know immediately. If you don't have dedicated security staff, your IT leadership needs to know. The people who handle the technical response need to be engaged.
From there, notify whoever handles legal and regulatory compliance if your incident might have regulatory implications. If customer data is at risk, your privacy officer or privacy counsel needs to know. If this is a potential breach that might require notification, your legal team needs to be involved because notification timelines are often legally mandated.
Notify your leadership, at least the person responsible for your IT or security function. They need to be aware so they can manage organizational response and be prepared for escalation.
The specific people you notify depends on your organization's incident response plan. The key is that you've already documented who needs to know in advance, so you're not trying to figure out the chain of command in the middle of a crisis.
Containing the Incident
Once you've confirmed an incident and notified the appropriate people, you often need to move fast to stop ongoing damage. The specific containment actions depend on what's happening, but the principle is the same: stop the active threat without making investigation harder.
If the incident involves a compromised user account, disable the account to prevent further unauthorized access. If you're concerned about lateral movement, you might isolate the compromised account to limited access while you investigate.
If the incident involves a system that's been compromised, take it offline if possible. This stops any further activity the attacker might do, but preserve the system for forensic investigation. Don't shut down a compromised system, power it off, or reboot it without understanding how that might affect investigation.
If the incident involves data exfiltration happening in real time, block the external connection or disable the user's network access. Stop the data from leaving, even if it means some disruption.
If the incident is malware, you might isolate affected systems from the network to prevent spread while you figure out what you're dealing with.
The key is to balance stopping the immediate problem with preserving evidence and not making things worse. Sometimes the fastest way to contain an incident is the slowest way to investigate it, so you're making tactical choices about what matters most.
Investigating What Actually Happened
Now that you've stopped the immediate problem, you need to understand what actually happened. Investigation is where you spend most of your time in an incident, and it's where you gather the evidence that informs whether this is a breach that requires notification.
Start by understanding the entry point. How did the attacker or the problem originate? Was a user credential compromised? Was a vulnerability exploited? Was a phishing email the origin? Understanding how the attacker got in tells you what to look for in preventing future incidents.
From there, trace the attacker's path. What systems did they access after the initial compromise? What data did they interact with? Did they move laterally to other systems? You're mapping the scope of the incident.
Determine what data was actually accessed or stolen. This is critical for breach notification decisions. Did the attacker access customer personal information, financial data, intellectual property, or something less sensitive? What's the volume of data? Did they look at it or take it? Did they modify it? The answers to these questions determine your notification obligations.
Document everything you find. Keep logs of what you've checked, what you found, what tools you used, and what your conclusions are. This creates a record for investigation, litigation, or regulatory inquiry if necessary.
If you have the expertise in-house, do the investigation. If you don't, engage external forensic experts. A forensic investigation by someone who knows what they're doing is expensive but valuable. It produces a credible account of what happened that can be used in legal proceedings or with regulators if necessary.
Managing Communication During the Incident
Communication happens throughout the incident response, not just at the end. Different audiences need different information at different times.
For affected customers or users, communicate what you know so far, acknowledge the incident, and commit to keeping them updated. Don't speculate or promise outcomes before you know what happened. Say something like: we've identified unusual activity on your account, we're investigating, and we'll provide an update by X time.
For your organization internally, communicate to staff what they need to know about the incident and what they need to do. If there's user-facing impact, let them know. If you're asking people to change passwords or enable additional authentication, communicate why and how.
For external parties like vendors or partners, communicate only what they need to know. If they're affected, tell them. If they're not, you might not need to inform them yet.
As you learn more, update your communications. Don't wait until you have complete information to give initial notification. The first communication might be: we've detected suspicious activity, we're investigating, and here's what we recommend you do immediately. A follow-up communication might provide more details about scope and timeline for recovery.
Recovery and Restoration
Once you understand what happened and you've contained the incident, you bring systems back to normal. The specific steps depend on what happened, but the principle is that you can't just reactivate a compromised account or bring a system back online without being sure it's actually clean.
For compromised accounts, change the password, enable additional security controls like multi-factor authentication, and verify that the account isn't still being used by an attacker before returning it to the user.
For compromised systems, either reimage them from clean media or use other remediation approaches to remove the attacker's footprint. Don't just remove the malware and bring the system back. Reimaging ensures the system is actually clean.
For systems that had data accessed, evaluate whether you need additional controls. Do you need enhanced monitoring on these systems? Are there specific systems this attacker accessed that need additional scrutiny?
Bring systems back online in a phased approach rather than all at once. This reduces the risk that if something went wrong in your remediation, the problem is limited rather than affecting your entire environment.
Post-Incident Learning
After the immediate incident response is over, do a retrospective. What allowed this incident to happen? What controls failed? What early warning signs did you miss?
Document the incident thoroughly. Write up what happened, how you detected it, how you contained it, what you found, and what the impact was. Keep this documentation for your records, for regulatory inquiry if necessary, and for organizational learning.
Identify the gaps in your controls that the incident revealed. Did you not have monitoring in the right place? Was access control not working the way you thought? Did you have a process that failed? Identifying gaps is valuable.
From the gaps, identify what you're going to fix. Maybe you need better monitoring. Maybe you need to strengthen access controls. Maybe you need to improve your security awareness training. Maybe you need to update your incident response playbook based on what you learned.
Prioritize the fixes. Not everything needs to be done immediately, but the gaps that are most likely to affect future incidents should get addressed relatively quickly.
Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about incident response as of its publication date. Standards, requirements, and best practices evolve — consult a qualified compliance professional for guidance specific to your organization.