What is cybersecurity incident response and how can it be managed in IT?

No one likes it, but let’s start with a hard truth: When it comes to cybersecurity incidents, the question is not whether they will happen, but when. And when something in life is inevitable, there are only two things we can do: prepare as best as we can and respond as best as we can when it happens. Today, we’ll focus deeply on the second one.
Generative AI is further boosting phishing attacks, hackers are using increasingly sophisticated methods, and malicious actors are multiplying, including state-sponsored ones in a tense global environment. In other words, today’s cybersecurity professionals are like a handful of colonial marines surrounded by aliens.
And more keep coming.
That’s why the thin line between catastrophic crisis and controlled damage during an incident is made of our methodical response process.

What is security incident response?

A methodical process is key, because running around like headless chickens putting out fires never works when it comes to incidents, since:

• Malicious actors will exploit any oversight during resolution to continue causing harm.
• Cybersecurity legislation will come down on us with hefty fines (adding to the losses from the attack itself) if our response is poor.

That’s why cybersecurity incident management is a systematic process to detect, contain and eradicate threats that compromise the confidentiality, integrity or availability of digital assets.
We execute this response by:

• Integrating specialized teams (SOC, CSIRT…).
• Key technologies and tools (SIEM, SOAR, IDS…).
• Best practices based on standards such as NIST SP 800-61r2 or ISO/IEC 27035.

With this, we aim to achieve the main goals of good incident response:

• Minimize operational and reputational damage
• Reduce detection and containment time (MTTD/MTTR)
• Meet legal requirements (GDPR, NIS2…)
• Use incidents as opportunities to become stronger against future threats.

Key elements of an incident response plan

Before reviewing the steps of the recipe, we must clearly understand and prepare the necessary ingredients. Therefore, here are the key elements of an incident response plan.

Component	Description	Example
Defined roles	Clear responsibilities during incidents.	Incident response leader, forensic analyst, communications lead, etc.
Technical playbooks	Procedures for specific types of incidents.	Ransomware playbook with containment steps.
Communication matrix	Protocols for notifying stakeholders.	Alert the Data Protection Agency within <72h in case of personal data breach.
Asset inventory	Mapping critical systems and their dependencies to know the territory inside out.	Maintain an excellent CMDB like the one integrated in Pandora SIEM.

Process stages: From incident to recovery

Reinventing the wheel makes no sense when we can fit our car with proven tires. So, let’s go step by step through how to manage a security incident. For clarity and practical purposes, the structure of steps used here aligns with best practices from NIST SP 800-61r2.
In fact, any good incident management follows the stages outlined below. Some frameworks group them differently (like ISO 27035), but any effective response to a cybersecurity incident will go through the following stage.

Stage 1: Preparation

In contact sports, you often hear the proverb: Hard training, easy fight. Cybersecurity is no different—it’s a full-contact fight, and the same logic applies. The more we prepare before an incident, the faster and easier the response will be.
The goal of this stage is to build a fortress with the most formidable defenders on the walls. Or in corporate terms, when selling the incident response plan to the board: Build proactive resilience.
Some critical actions in this stage include:

• System hardening (patching, secure configuration…)
• Drills and/or tabletop exercises for teams, or Red Team / pentesting practices.
• Installation and custom configuration of the SIEM…

Stage 2: Identification

Not all smoke means fire in cybersecurity, or at least not all cases require pulling out the big truck and sirens. That’s why the main goal is to validate and classify suspicious events.
This is where a SIEM tool like Pandora SIEM shines, making life easier.
Common techniques today in this stage include:

• Event correlation in SIEM.
• IOC (Indicators of Compromise) and behavior analysis with an EDR. This goes beyond signature-based or overly simplistic heuristics used by traditional antivirus tools.

The ideal scenario combines SIEM with EDR. A practical example would be Pandora SIEM detecting anomalous connections to C2 (Command & Control) IPs by correlating firewall logs and endpoint data (via EDR or installed agent).

Stage 3: Containment

It’s happened. The previous two steps couldn’t stop the threat in time, and now there are rats in the walls (a geeky literary reference, perhaps).
In this stage, the goal is to limit the spreadout.
First, we normally use short-term strategies—like applying a tourniquet in battle—by isolating network segments, endpoints, etc. Then we implement broader actions, such as resetting compromised credentials.
In quick short-term containment, automation can help, and this is where SOAR shines by executing playbooks.
A playbook example for the anomalous connection mentioned in the previous stage could be:

• Block the malicious IP in the firewall.
• Isolate the infected endpoint via EDR integration.
• Create a ticket in Pandora ITSM for the forensic team.

Stage 4: Eradication

Time to eliminate those rats—and more importantly, any hidden surprises like APTs (Advanced Persistent Threats) that might maintain residual access after incident handling. For example, a UEFI rootkit can survive OS reinstallation.
The point here is not to remove symptoms, but to eliminate root causes with actions such as:

• Malware eradication.
• Patching exploited vulnerabilities (e.g., CVE-2023-34362).

The key in this stage is that proper eradication requires not just a flamethrower, but a complete understanding of what happened.
If we don’t know how the attacker got through the wall or can’t locate that rootkit in the BIOS, it’s like killing cockroaches without finding the nest. Tomorrow night, party’s back on as soon as we turn on the kitchen light.

Stage 5: Recovery

In this stage, the goal is not just to get things back to normal, as the song says, but to restore service with reinforced controls.
In other words, we come back stronger and safer. Key practices here include:

• Restoration from immutable backups.
• Post-recovery monitoring to detect residual activity (like potential APTs or suspicious behavior).

Stage 6: Post-mortem review

Since the goal is to become stronger through adversity, the key here is to learn what happened, why it happened, and what we’ve done to prevent it from happening again.
The practical deliverable in this stage might be:

• A report with the incident timeline and identified ATT&CK techniques used against us.
• An update of playbooks and detection rules to prove we’ve really evolved.

Incident Response Teams: CSIRT, CERT, and SOC

When facing an incident, the human teams involved will depend on the organization’s structure and available resources.
Usually, if the organization has a certain size, there will be a SOC (Security Operations Center) responsible for daily monitoring and preventive tasks.
The more effective their work, the lower the chances of incidents.
Then there is the CSIRT (Computer Security Incident Response Team) and/or CERT (Computer Emergency Response Team). What’s the difference? In practice, very little. But in cybersecurity, acronyms are popular, and CERT is a registered term by Carnegie Mellon University. In general, it refers to specialized incident response teams who know this field like the back of their hand.
Often, an organization won’t have a CSIRT/CERT. In that case, cybersecurity companies offer response teams you can hire to handle the incident if your internal team is overwhelmed.
This table summarizes their roles.

Team	Main Function	Key Differentiators
SOC (Security Operations Center)	24/7 proactive monitoring	Focus on early detection and operational response
CSIRT/CERT	Handling critical incidents	Specialized in forensic analysis and crisis coordination

Essential technological tools

Good luck showing up to an orbital bombardment with a wooden sword—malicious actors today seem to have unlimited photon torpedoes.
The truth is, cybersecurity has become so complex and unmanageable that we cannot properly handle an incident without specialized tools that help detect, mitigate, and analyze—essentially, to lift a weight that’s nearly impossible to manage manually.
Among these incident response tools, key ones include:

SIEM (Security Information Event Management)

An application that works like the Eye of Sauron across your IT infrastructure. Or at least everything it’s connected to—usually through agents installed on all kinds of devices, sending activity data.
Its strength lies in the centralized correlation of those logs.
The most advanced SIEM systems, like Pandora SIEM, also use artificial intelligence to detect complex attack patterns, which are becoming increasingly sophisticated at evading detection.
Its power lies in instant and extensive analysis, along with alert customization for potential incidents, increasing the chance of stopping them before they breach the wall.

SOAR (Security Orchestration, Automation Response)

If SIEM’s strength is analysis, SOAR’s is its ability to deploy automated actions based on that analysis.
This provides a massive advantage in very short-term incident response—stopping the fire while it’s still a spark.
It operates by executing automated playbooks.
For example, a phishing response playbook could:

• Isolate the click-happy compromised user.
• Remove malicious emails from inboxes.
• Send an alert to the SOC for investigation.

As we can see, SIEM and SOAR can collaborate for optimal incident management, and today, the boundaries between these tools are increasingly blurred. Some SIEMs include automated response capabilities, and some SOARs include SIEM features, depending on the solution.

EDR/XDR (Endpoint Detection Response / Extended Detection Response)

This software is installed on endpoints and monitors them. Like traditional antivirus, it can act on threats, but we’re talking about a much more advanced evolution than signature-based checks.
When connected to a SIEM, it can feed data for analysis, and if response is supported, the SIEM can instruct the EDR to take action.
For example, in a ransomware incident, an EDR might quarantine the affected device, mitigating the threat and saving lots of effort.
Other useful tools depending on the organization and IT infrastructure might include:

• UEBA (User and Entity Behavior Analytics): goes beyond classic malware detection by spotting suspicious user or system behavior.
• IDS/IPS (Intrusion Detection/Protection Systems): used to detect and block malicious network traffic.

Incident Response Use Cases

Every incident and organization is different, but here are some examples of security incidents and their life cycle from a high-level view.

Case 1: Ransomware Attack

The classic that never stops causing trouble. Someone clicks where they shouldn’t, and the party begins. This would be the basic incident management process:

• Identification: The infected device’s EDR alerts about massive file encryption. The alarm is triggered.
• Containment: The organization has SOAR, which isolates affected endpoints in under 5 minutes. The SOC investigates.
• Eradication: Malware is removed, and if phishing was the entry point, the user gets re-educated—others are warned too. Clean backups are restored.
• Lesson learned: Perhaps the organization needed better network segmentation, as the spread reached areas it shouldn’t have.

Case 2: Data Leak from an Insider Threat

In this case, the enemy is within. A disgruntled employee, fed up with cybersecurity awareness training, decides to take matters into their own hands.

• Identification: Pandora SIEM detects unusual downloads by the user via EDR logs.
• Containment: An alert is triggered and the EDR blocks the device. Pandora SIEM sends an alert to the SOC and opens a ticket in ITSM.
• Recovery: Pandora SIEM shows the access log timeline to see if the user tried anything similar in the past. The potential data breach is investigated, and measures are taken against the user.
• Post-mortem improvement: A stricter DLP (Data Loss Prevention) policy is implemented.

Case 3: DDoS Attack

A denial-of-service incident is another timeless classic affecting websites, services, etc.

• Identification: The IDS detects a spike in UDP traffic on the network.
• Containment: Traffic is redirected to a Scrubbing Center, fortunately built as a personal project by a geeky intern while everyone else laughed.
• Post-mortem improvement: A clear plan was missing, so the intern gets promoted, and talks start with Cloudflare (for example) to contract anti-DDoS protection.

As we can see, incident management stages aren’t set in stone and should be adapted as a flexible framework.
For example, in a DDoS or insider data exfiltration, the eradication stage may not apply (unless the organization is Tony Soprano’s crew, and “eradication” refers to the user).

How Pandora SIEM Optimizes Incident Response

We’d love to tell you that Pandora SIEM will make learning all of this unnecessary because it will protect you 100% from incidents. But no one can promise that. And if someone does—run (in the opposite direction).
What we can say is that Pandora SIEM:

Minimizes the likelihood of an incident taking place as much as possible.

Reduces the time needed to resolve the security incident.

How? In 3 main ways.

1. Advanced Correlation

The real power lies in its advanced event correlation—individually harmless events that together signal disaster.
It has custom rules to detect complex attack patterns, combining all available information like a Palantir that warns us when hobbits sneak in with a dangerous ring.

2. Unified Incident Management

Natively integrated with Pandora ITSM, Pandora SIEM lets you manage the entire incident lifecycle from a single platform, including:

• Customizable ticket system to track actions, status, and responsibilities.
• Integrated CMDB to understand each asset, its status, and its event history.
• Change management tracking.
• SLA control in case service levels are impacted by the incident.
• Automated actions via SOAR integration and more.

3. Clear and Complete Post-Mortem Insight

After an incident, accountability is required. Sometimes not only to managers or customers—a data breach may require notifying the Data Protection Agency or undergoing an audit if you’re a critical infrastructure organization.
Pandora makes this easier by consolidating all relevant data and allowing clear reconstruction of the incident.
This provides the ultimate advantage I’ll never stop repeating: Deep understanding of what happened.

Best Practices and Common Mistakes in Incident Management

We’re reaching the end of the road, and it’s worth highlighting some mistakes and best practices in security incident handling.
Regarding mistakes, at Pandora we’ve observed all-too-common patterns such as:

• Isolated technology silos between SIEM, EDR, ITSM… That fragmentation blinds us to complex attacks and hinders both detection and resolution.
• Ignoring post-mortem review and improvement. Because we all know how meetings go—everyone agrees, nods, and then comes that strange amnesia that makes everything stay the same.

As for best practices, aside from simply avoiding the mistakes above, it’s recommended to:

• Conduct quarterly incident simulations.
• Implement automation for basic responses.
• Maintain immutable and offline backups.

The reality is that sooner or later, an incident will happen. I could quote chilling statistics on the current prevalence, but stats don’t really persuade—and frankly, I believe they fall short. After all, the best hacker is the one you never detect, and I’ve met some that seem like wizards.
That’s why the key to incident management lies in remembering that horrible but true corporate phrase: Proactive resilience.
In other words, we must harden our defenses and never lower our guard, constantly learning and applying new techniques and tools. After all, that’s exactly what malicious actors are doing—they are proof that continuous improvement is not a myth.