The 5 stages of incident response grief

Whether we recognize it or not, anytime an incident occurs, it sets off the grieving process. But grief isn’t a bad thing: it’s how we process our emotional reactions and move on. That’s precisely what security teams need to do in the wake of a cyber incident—and you’d be surprised how well the stages of incident response map to the famous “Five Stages of Grief.”

Starting with denial and moving through anger, bargaining, depression, and acceptance, security experts can take a few lessons from the grieving process:

Denial (analysis)

In many ways, denial is the most difficult stage of grief. Suppose you’re a security or IT professional. In that case, it can be difficult to accept that an intruder may have breached your defenses and gotten into your systems—and when you first see the evidence of an incident in progress, you might first consider alternate explanations. Is it a false alarm? Did an employee open the wrong application by mistake? Maybe an automated process is misfiring, or a misconfiguration is causing an alert to trigger. You want to consider your options before assuming the worst.

But in your heart, you probably know the truth. It’s impossible to stop 100% of attacks, so incidents will eventually happen. Getting past the denial stage starts with gathering information—understanding where the incident is occurring, what is happening, and what the attacker’s goals might be. Once you accept that a security incident is in progress, you can take the next step toward addressing it.

Anger (containment)

Anger and frustration are common responses to an incident in progress, but CISOs and other security leaders can help channel those reactions into action. Once you confirm that it isn’t a false alarm and there is, in fact, an attacker present in the system, your first thought is probably, “this is going to consume the next few days, weeks, or months of my life.” You may become angry at a specific team for not following security guidelines or shortcutting a process. Hopefully the attack was detected quickly enough to mitigate the incident before significant damage can be done—but if the attack is severe, it will probably take time to rectify. That’s enough to make anyone angry.

Channeling that anger toward containment is essential. Once an attacker has been identified in your systems, you’ve passed the prevention stage, and you now need to focus on reducing the blast radius of impact and any further lateral movement. That might mean shutting down certain systems or quarantining areas of the network where evidence of intrusion is present. The specific steps you take will depend on the nature of the security incident and how severe it is, but it’s important not to let your frustration slow you down. If the incident gets worse, it will only make you angrier – but you can’t let that blind you.

While no one wants an incident to occur, there are some positive outcomes. For instance, most of the time, the shared anger across teams will break down communication siloes or political barriers, and departments that were experiencing friction with security before are now working in lockstep against a common enemy.

Remember, when dealing with breached data, the main goal is to “drive the value to zero.” That means in addition to containing the threat from a technical perspective, it’s essential to evaluate the economics of the data exposed and take action to inactivate it. For example, if the attack included an SQLi to steal a table containing (hopefully hashed) passwords, forcing a password change and identity validation during that process will render that stolen data useless.

Bargaining (eradication)

Whatever is in your system needs to be removed—and you need to make sure it can’t get back in. If you’ve successfully contained the incident during the previous stage, this is the next logical step. But it isn’t always easy. You may have to come to grips with the fact that certain data has been encrypted or stolen, or certain systems have been corrupted beyond repair. Some may have backup systems, others may not. Some may be easy to restore, others may take time. There isn’t always a quick and easy solution, and that can be hard for security teams to accept.

Stopping an incident in progress always requires some level of bargaining. If only I had deployed XYZ agent to these systems, this wouldn’t have happened. That budget request that was denied last year would have given me more headcount. Please, please, please don’t let me find another persistence method after all this work.

Sadly, getting an intruder out of your system is rarely a quick and easy process. But understanding the layout of your digital landscape and working with stakeholders throughout the organization can help ensure you’re making the right decisions at the right time. There is a time to reflect on what could or would have stopped the incident in the first place, but the eradication stage isn’t that time – at this point, it will only distract you.

Depression (recovery)

The incident has been confirmed and contained, and the threat actor has been removed. Now, it’s time to work with the other stakeholders to bring systems back online correctly.

Are there systems that need to be restored from backups? Who can make that happen, and how long will it take? Can other systems be brought back online immediately, or are there steps the IT team needs to take to ensure they are clean and secure? Are there external partners that need to be consulted? What are the protocols for informing impacted customers? If we restore from backups, how much data will we have lost? What are the downstream effects of data misalignment across integrated systems? Now that the organization is beginning to breathe a little easier, addressing these concerns is essential.

And let’s not forget about the crisis communication protocols – informing the Board, communicating to customers and regulators, documenting for audits, and taking other steps to correctly handle the incident with integrity. The good news is incidents happen, and the industry has generally embraced that as a fact. Some customers may be upset and question the security of their data, but when businesses respond to an incident effectively and ethically, most will appreciate the transparency – especially proactive communication that outlines the clear steps being taken to remedy the issue. Businesses and customers increasingly recognize that incidents happen.

Acceptance (postmortem)

Finally, acceptance. With the recovery process well underway, it’s time to take what you’ve learned and apply it. Now is the time to start bringing in all those suppressed thoughts from the former stages.

That begins with understanding what went wrong. What was the cyber kill chain? What vulnerabilities did they exploit to gain access to certain systems? How did they evade detection solutions? Are certain solutions not working as well as they should? Did we have unexpected blind spots? Are additional controls needed to compensate? Were any regulatory or compliance standards impacted, and do they need to be reported or addressed? Did our incident response process work and how can we make it better? Understanding what went wrong is the first step toward making sure it can’t happen again.

You may not be able to stop every attack, but you can avoid falling for the same trick twice. That might mean implementing new security solutions. It might mean better compartmentalizing your security architecture. It might also mean looking into the people and processes involved in the breach and determining where there are opportunities for improvement.

Accepting that breaches happen is important, but acceptance doesn’t mean complacency. Arming yourself with information allows you to take a more data-driven proactive approach, ensuring the subsequent breach will be much easier to stop.

Channeling grief into action

Grief is a universal experience, which means we have a pretty good understanding of how to process it and use it to our advantage—even if it’s sometimes challenging. Allowing yourself to move thoughtfully and carefully through each stage of incident response grief gives you a valuable checklist that can help contain an event in progress and ensure you are well-positioned to prevent similar incidents.

Stages like “anger” and “depression” are a necessary part of the recovery process, but don’t let them bog you down – instead, let them motivate you to take the actions needed to create a stronger, more secure environment in the future.