How incident management works — step by step

A cyber incident can happen at any time. It could be ransomware encrypting your files in the middle of the night, a data breach that's been going on for weeks without anyone noticing, or a phishing attack that gave an attacker access to an admin account. What determines how bad it gets is rarely the nature of the attack, it's how quickly and methodically you respond.

That's what incident management is about.

What is incident management?

Incident management is the structured process for identifying, containing, investigating, and recovering from a security incident. It covers the technical work, external communications, and the legal aftermath.  

Many people confuse incident management with crisis management. Crisis management is broader and covers everything from natural disasters to PR crises. Incident management is specifically focused on IT security incidents and follows a well-defined process with clear roles and phases.  

A common misconception is that having an incident management plan on paper is enough. A plan that's never been tested is effectively useless during an active attack. Stress, time pressure, and unclear roles mean that untested documentation rarely gets followed. The plan has to be practiced, and the roles have to be second nature.

‍

The six phases of incident management

Established incident management frameworks divide the process into six phases. They look like a linear sequence, but in practice several of them overlap, especially during an active incident.

‍

Phase 1: Preparation

Everything starts before the incident happens. The preparation phase is about building the capacity to actually handle an incident. That includes defining roles and responsibilities, developing an incident management plan, establishing communication channels, and setting up the technical tools needed for logging and detection. Organizations that invest properly in preparation handle incidents faster, limit damage more effectively, and recover with fewer complications.

‍

Phase 2: Identification

Something seems off. Maybe a system is unusually slow, a user has logged in from an unexpected country, or an alert has triggered in your SIEM. The identification phase is about determining whether you're actually dealing with an incident, and if so, what happened, which systems are affected, and how serious it is. Inaccurate or delayed identification is one of the most common mistakes during incidents, and every hour of delay gives the attacker more room to operate.

‍

Phase 3: Containment

The goal is to stop the spread. That might mean isolating affected systems from the network, blocking specific IP addresses, disabling user accounts, or segmenting parts of the infrastructure. It's important to distinguish between short-term containment, quickly limiting the damage, and long-term containment, which means more sustainable measures while the investigation continues. Shutting down systems too early, before evidence has been secured, is a common mistake that can complicate the forensic investigation.

‍

Phase 4: Eradication

Once the spread is contained, the work of actually removing the threat begins. That can mean removing malware, closing backdoors, revoking compromised credentials, and patching the vulnerabilities the attacker exploited. The eradication phase often requires deep technical expertise and forensic analysis to make sure the attacker is no longer in the environment, hiding in a system you haven't looked at yet.

‍

Phase 5: Recovery

The systems are clean. Now it's about gradually bringing them back online and verifying that they're functioning correctly, with no remaining threats. Recovery usually happens in stages, the most critical systems are prioritized and each one is closely monitored before the next is brought up. It's not uncommon for the recovery phase to take weeks or months, especially after ransomware attacks where the backup strategy wasn't solid enough.

‍

Phase 6: Lessons Learned

The incident is handled, but the work isn't done. Two to four weeks after the incident is closed, a structured review takes place, a lessons learned session where the entire sequence of events is walked through. What worked? What didn't? What should we have caught earlier? The findings are used to update the incident management plan, improve detection capabilities, and make sure the same incident can't happen again.

‍

Roles and responsibilities during an incident

An incident is the wrong time to discuss who does what. Those roles need to be defined and practiced in advance.

The incident commander leads the response and makes decisions under pressure. This isn't necessarily the most technically skilled person, it's the person who can hold the big picture together, communicate up to leadership, and keep the work moving forward even when the situation is unclear.

The technical lead is responsible for the forensic investigation and technical actions: isolating systems, analyzing logs, and removing the threat. In a complex incident, multiple specialists may be needed with responsibility for different parts of the infrastructure.

The communications lead handles all external communication, to customers, vendors, and if necessary the media, as well as internal communication to employees. It's a role that requires good judgment and is often underestimated during active incidents.

Legal and compliance need to be involved early, especially if personal data may have been stolen. Reporting deadlines are tight, and the legal aftermath can be costly if it's mishandled from the start.

Leadership needs regular updates and is ultimately responsible for business-critical decisions, such as whether operations should be temporarily shut down or whether to proactively communicate to customers.

‍

Communication during an incident

Communication during an active incident is hard. There's a natural pull toward saying as little as possible to avoid alarm, but under-communication often causes more damage than transparency.

Internally, employees need to know what's happening, what they're expected to do, and what they shouldn't do. A common instruction is to not discuss the incident externally until the communications lead has approved it, to prevent inaccurate information from spreading.

Externally, you need to determine whether customers or vendors are affected and when they should be informed. Late communication that feels like a cover-up is often more damaging to trust than early communication that acknowledges what happened.

Regulatory reporting is not optional. For personal data breaches, you're required to notify IMY within 72 hours under GDPR. For incidents in organizations covered by NIS2, a preliminary report to the relevant supervisory authority is required within 24 hours, and a more complete report within 72 hours. CERT-SE is the national point of contact and can provide operational support during serious incidents.

Common mistakes during incidents

Many of the mistakes made during incidents are predictable. That means they can be prevented.

• Shutting down systems too early. It might seem logical to immediately shut down a compromised system, but it can destroy critical evidence and complicate the forensic investigation. Isolation is almost always better than a full shutdown.

• Communicating too late. Waiting to inform customers or regulators until you have "the full picture" often means missing deadlines and damaging trust more than necessary.

• Not having a tested backup strategy. It's not uncommon for organizations hit by ransomware to discover that their backups are either encrypted along with everything else, or were never tested for recovery.

• Not documenting in real time. During an active incident, it's easy to focus on the technical work and forget to keep a log. That makes both lessons learned and any legal proceedings significantly harder.

• Underestimating lateral movement. An attacker who's gotten into one system has often moved further into the network. Focusing only on the first compromised system can leave the threat sitting elsewhere in your environment.

• Resolving the incident without understanding the root cause. Cleaning up and restoring without identifying how the attacker got in means the door is still open.
• ‍

When should you bring in outside help?

Not every incident requires external support, but in some situations getting the right expertise in quickly is critical.

Bring in outside help if the attack is still ongoing and you don't have the capacity to stop it, if your internal expertise isn't sufficient for a forensic investigation, if compliance requirements mean the investigation needs to be documented by an independent party, or if the scope of the incident is unknown.

Cyloq can be brought in on an emergency basis, even if you're not an existing customer. The first call is always free to assess the situation, and the contract and scope are defined in parallel with starting the response, so that nothing is delayed. The earlier you call, the more options you have.

Contact us