How does an Incident Response team stop a cyberattack, step by step?

It is 02:17. EDR detects an unusual process launch on a user’s workstation, and SIEM links it to a corporate cloud sign-in from a new location. Email works, servers respond and employees are asleep. From a business perspective, nothing has happened yet. For the security team, a race against time has just begun.

The illustrative timeline below shows how an Incident Response team might stop a developing cyberattack, from the first alert to regaining control. The times illustrate the process; they do not describe a specific customer’s incident, state an SLA or guarantee an outcome.

What should you know?

• An alert is not yet an incident. First, the signals must be connected, their credibility assessed and their impact on the organisation established.
• Incident Response is a team effort. The SOC analyses and escalates, IR specialists lead containment, and administrators and business owners perform or authorise actions in the environment.
• Isolation must be coordinated. Disconnecting a host or account within minutes may be appropriate, but shutting down a system without considering the consequences can hinder analysis, destroy volatile data or stop a critical process.
• The first 90 minutes are about regaining the initiative. The team must confirm the incident, restrict the attacker’s access, assess the scope and protect critical systems.
• Closing the alert does not finish the work. Without addressing the cause, restoring safely, reporting and learning lessons, the same problem may return.

Why an alert alone does not stop a cyberattack

An organisation may have firewalls, EDR/XDR, SIEM, backups and extensive dashboards yet still lose control of an incident. The problem is often not a missing signal, but the gap between detection and a decision.

Who analyses an alert at 02:17? Who can block an administrator account? Is automatic isolation of a production server permitted? How do you contact a decision-maker if corporate email may be compromised? Without answers, technology merely records events as they unfold.

The consequences affect the business: wider compromise, longer downtime, the risk of data loss or disclosure, more difficult recovery and confused communication. That is why MTTD and MTTR are not merely technical metrics. They show how quickly the organisation moves from a threat to an informed decision and regained control.

In the opening minutes, the team does not try to fix everything. It first builds a credible picture, restricts the most likely paths for further attack and protects the organisation’s ability to make subsequent decisions.

02:17 — minute 0: detecting the first signal

EDR records behaviour outside the workstation’s usual profile. The signal alone does not establish an attack: similar activity could come from a legitimate administrator script, an update or a misclassification.

SIEM compares the alert with other data. During the same period, a user logged in from an unusual location, attempted to access an unfamiliar resource and changed the authentication method. Each event may appear harmless alone. Correlation brings the story together.

The SOC analyst checks:

• the account, device, time and source of activity;
• the user’s and device’s previous behaviour;
• related alerts from EDR/XDR, SIEM, identity, network and cloud sources;
• the asset’s criticality and importance to business processes;
• whether a similar pattern appears on other hosts or accounts.

The objective at this stage is not to explain the entire incident. It is to determine whether the signal needs immediate analysis and whether the threat may be developing.

02:18–02:27 — minutes 1–10: confirming the incident

Triage begins. The analyst checks data quality, rules out obvious false positives and seeks confirmation from independent sources. The unusual login proves inconsistent with the user’s normal profile, and a suspicious workstation process established communication unrelated to any known business application.

At 02:25, the alert changes status. It is no longer an isolated anomaly but a probable incident involving an account and an endpoint. The analyst assigns an initial priority based on four questions:

1. How credible is the available evidence?
2. Which assets may be at risk?
3. Is the activity still ongoing?
4. What could the impact be on business continuity, data and customers?

By 02:27, the team has enough information to activate the playbook for a compromised account and potentially compromised workstation. It does not yet know the full cause or scope. Incident Response does not wait for complete knowledge: it acts on the best available picture, recording assumptions and updating decisions as evidence emerges.

02:27–02:47 — minutes 10–30: initial actions

Once the incident is confirmed, an Incident Response specialist joins. The SOC hands over the context, timeline, indicators of compromise and initial impact assessment. The agreed escalation path to the customer’s IT team is activated in parallel.

The most urgent actions may include:

• isolating the affected workstation while retaining EDR telemetry;
• blocking or temporarily restricting the account;
• revoking active sessions and tokens;
• restricting communication with identified destinations;
• preserving logs, volatile data and other evidence;
• applying heightened monitoring to related accounts and systems;
• notifying the business owner of the potential impact of protective actions.

Every action has an owner, execution time and rationale. If isolation could stop a critical process, the IR team presents both the risk of continued attack and the business risk of disconnection. An authorised person decides under the agreed model, avoiding a late-night search for approval.

Effectiveness at this stage depends on preparation before the incident. Without round-the-clock analysis, a contact matrix, isolation authority and rehearsed playbooks, the first half-hour becomes a series of calls and disputes over responsibility. If the internal team cannot provide that availability, properly prepared incident response should shorten this path: from signal, through assessment, to controlled action.

02:47–03:47 — minutes 30–90: stopping the spread

Isolating the first device reduces one source of risk, but does not prove the incident has been contained. The attacker may have used another account, established persistence or reached further systems. The team moves from a focused response to scoping the incident.

The SOC and IR team seek answers to these questions:

• whether similar behaviour occurred on other devices;
• whether the account acquired new privileges;
• which assets and data were accessed;
• whether there has been lateral movement;
• whether identity, backup, virtualisation or management systems are at risk;
• which log sources are complete and where visibility gaps exist.

The customer’s administrators provide context the tools lack: whether an overnight job was planned, which server supports a critical process and which dependencies a block could affect. IR coordinates further containment while the SOC continuously observes changes in the environment after isolation.

If analysis indicates a threat to a wider segment, the team may progressively restrict communication, reset credentials in a safe sequence and protect recovery systems. The objective is not to block as much as possible. It is to prevent further attacker activity without causing uncontrolled downtime.

The following hours — regaining control

Containment is not the same as eliminating the threat. Once activity has been stopped, the team identifies the entry mechanism, removes unauthorised changes, closes exploited gaps and checks for other access paths.

Before restoring systems, three questions must be answered:

1. Is the likely cause understood and has it been addressed?
2. Are the recovery point and target environment trustworthy?
3. Can the organisation detect another attempt using the same method?

Services return according to business priorities rather than an arbitrary sequence. Dependencies needed by critical processes come first, followed by integrity, functional and security checks. Heightened monitoring continues after recovery, because the absence of another alert does not prove complete eradication.

If the incident affected data or the entire environment, recovery from isolated, verified backups or activation of a Disaster Recovery environment may be needed. In this scenario, the IR process should be linked with SecureVault and BCP/DR plans, so returning to operation does not restore the same vulnerability.

Why 'switch everything off’ is not a plan

The myth is simple: when an attack is detected, disconnect the computer or shut down the server. In practice, that may be appropriate, but only as part of coordinated containment.

A sudden shutdown may destroy volatile evidence, interrupt telemetry, affect the safety of an industrial process or stop a critical service. Leaving an active device connected may allow the attacker to continue. The IR team therefore assesses both risks and chooses a proportionate action.

CISA recommends coordinated system isolation, treating shutdown as a fallback when a device cannot safely be disconnected from the network. This illustrates a key principle: response should be fast, but not chaotic.

An incident response reference model

The timeline below structures an illustrative response. Actual stage durations depend on the attack, telemetry availability, permissions, environmental architecture and business impact.

Illustrative time	Stage	Primary objective	Example activities	Business outcome
02:17	Detection	Identify a credible signal	EDR alert, SIEM correlation and context review	Less time spent in uncertainty
02:18–02:27	Analysis and classification	Confirm the incident and assign priority	Triage, cross-source verification, assessment of activity and criticality	Distinguishing a real threat from noise
02:27–02:47	Escalation and containment	Restrict the ability to continue	Host isolation, account blocking, evidence preservation and customer contact	Reduced scope and faster decisions
02:47–03:47	Scoping the incident	Stop the spread	Threat hunting, account and host analysis, and protection of critical systems	Reduced lateral movement risk
The following hours	Eradication and recovery	Address the cause and restore services safely	Remediation, credential resets, recovery, testing and heightened monitoring	A controlled return to operation
After stabilisation	Lessons Learned	Reduce recurrence risk	Reporting, detection and playbook updates, and implementation of recommendations	Improved organisational resilience

This model aligns with an approach in which Incident Response runs throughout risk management rather than beginning only once damage has been confirmed. This perspective is also emphasised in the current publication NIST SP 800-61 Rev. 3.

Who is responsible for what during a cyberattack

Incident Response is not a one-person task. Even the best analyst does not know every business dependency and should not independently authorise stopping a critical service.

Role	Responsibility during the incident	Key decisions or actions
SOC analyst	Detection, triage, correlation and escalation	Whether the signal is credible, its priority and what information to pass to IR
Incident Responder / Incident Commander	Technical coordination and timeline management	Containment strategy, task allocation and situational updates
The customer’s IT team	Safely implementing changes in the environment	Asset isolation, access changes, and support for remediation and recovery
Business owner	Assessing impact and priorities	Approving service impact and the order of process restoration
Management / crisis team	Decisions with significant organisational impact	Priorities, resources, communication and risk acceptance
Legal / compliance / DPO	Assessing formal obligations	Whether and to whom the incident must be reported, and what information to preserve
Communication	Consistent information for employees, customers and partners	Communication channel, content and timing
Backup / DR	Preparing safe recovery	Selecting a recovery point, testing and activating the standby environment

Before an incident, agree not only roles but also deputies, out-of-hours availability and authority limits. A list of names without decision-making powers is not an escalation path.

Illustrative scenario: an overnight attack contained before escalation

The following scenario is educational. It does not describe a specific customer or a guaranteed service outcome.

At 02:17, the SOC receives an EDR alert from a finance employee’s workstation. Correlation with the identity system reveals an unusual login, while cloud logs show an attempt to access a resource the user had not previously used.

By 02:27, the analyst confirms that the events share a context and escalates the incident. An IR specialist activates the compromised-account playbook. EDR isolates the workstation, account sessions are revoked and evidence preserved. The customer’s administrator confirms the activity was unplanned.

Over the following tens of minutes, the team checks systems contacted by the workstation and accounts using the same resources. An attempt to use compromised credentials is detected on a second device, but persistent access is not confirmed. A service account receives additional restrictions, and critical systems are placed under heightened monitoring.

Before the working day begins, the organisation has control of the incident, a documented timeline and a remediation list. This does not mean the incident has disappeared. Root-cause analysis, relevant credential rotation, integrity checks and observation continue. The difference is that the team shares a common picture instead of learning about the problem from users in the morning.

What happens after containment

The best Incident Response improves organisational resilience. After stabilisation, a report should distinguish facts from hypotheses and answer at least these questions:

• what happened and when;
• which assets, accounts, data and processes may have been affected;
• what actions were taken, who authorised them and with what outcome;
• what the likely cause was;
• where visibility, permissions or clear ownership were missing;
• which recommendations take priority and who owns their implementation.

During Lessons Learned, the team updates SIEM and EDR/XDR rules, playbooks, contact lists, the escalation matrix and recovery scenarios. It also measures MTTD, time to classification, time to containment and time to safe restoration, with a clearly defined start and end for each measurement.

If the incident meets the significant-incident criteria for an entity subject to NIS2, the technical process must support reporting obligations. Article 23 of the NIS2 Directive provides, among other things, for an early warning within 24 hours of becoming aware, notification within 72 hours and, generally, a final report no later than one month after notification. Classification and the applicable procedure must be assessed under current law and the organisation’s circumstances; an alert alone does not automatically trigger a reporting obligation.

How to prepare before an alert arrives

IR readiness can be tested before a crisis. An organisation should have:

• security monitoring covering nights, weekends and holidays;
• agreed definitions of an event, an incident and a critical incident;
• playbooks covering at least ransomware, account compromise, data breaches and lateral movement;
• contact lists with deputies and a secure communication channel outside potentially compromised email;
• pre-authorised decisions and clear approval thresholds for isolating a host, account, segment or service;
• access to the required logs and retention sufficient to reconstruct events;
• protected, isolated and tested backups and a Disaster Recovery plan;
• tabletop exercises and technical tests of detection, escalation and recovery;
• a procedure for working with legal advisers, the DPO, communications teams and relevant authorities;
• a way to measure MTTD, MTTR and implementation of post-incident recommendations.

When selecting external support, check whether the offered incident response (IR) covers not only retrospective advice but also operational readiness, clear escalation and cooperation with the customer’s team. If an exercise cannot establish who authorises isolation at 02:17, the problem is not tool speed: it is the operating model. Start by reviewing data sources, permissions, playbooks and escalation paths before a real attack tests them. VigilHorizon can help with this assessment; current contact details are on the consultation page.

Summary

A single alert or person does not stop a cyberattack. The organisation’s ability to connect data quickly, assess risk, decide and act in a coordinated way does.

In the illustrative scenario, the first 90 minutes regain the initiative: confirming the incident, restricting access, preserving evidence, establishing scope and protecting critical systems. The following hours address the cause, restore safely and verify that the threat has actually been removed.

An organisation seeking to reduce MTTD and MTTR should combine technology with round-the-clock analysis, decision-making authority, rehearsed playbooks and business cooperation. VigilHorizon SOC 24/7 supports this model from event analysis through response and incident documentation.

Frequently asked questions (FAQ)

What is Incident Response?​

Incident Response is a structured process of preparation, detection, analysis, containment, remediation and safe restoration after a security incident. It includes technology, people, procedures, business decisions and lessons learned.

When is the Incident Response team activated?​

IR becomes involved when analysis confirms an incident or the risk is high enough to require immediate protective action. The precise threshold should follow the organisation’s incident classification and escalation process.

Does Incident Response operate 24/7?​

It can, but this requires appropriate staffing, on-call arrangements and procedures. An IR document alone does not provide overnight response. Organisations therefore connect IR with SOC 24/7.

How does a SOC differ from an Incident Response team?​

The SOC continuously monitors the environment, analyses alerts, correlates data and escalates suspicious events. IR leads work after confirmation: planning containment and coordinating scoping, remediation, recovery and Lessons Learned. In a mature model, both teams work as one process.

Should an attacked server be shut down immediately?​

Not always. Disconnection or shutdown may be necessary, but the decision should consider further attack risk, business importance, process safety and evidence preservation. Controlled network isolation with telemetry retained is often preferable.

How long does handling a security incident take?​

There is no single duration. Triage may take minutes, while scoping, addressing the cause and safe recovery can take hours or days. Factors include the attack type, environment size, log quality, team preparation and availability of safe backups.

Can SIEM or EDR/XDR stop a cyberattack independently?​

Tools can automatically detect or block selected actions, but do not replace impact assessment, coordination, business decisions or complete scoping. Deploying SIEM alone does not create a functioning response process.

What data does Incident Response need?​

Typically, logs from identity systems, endpoints, servers, networks, cloud, email and critical applications, plus business context: system ownership, service criticality, dependencies and planned changes. The scope depends on the incident.

Who can authorise system isolation?​

The responsibility matrix should define this. SOC or IR may be pre-authorised to isolate a workstation, while disconnecting a critical system may require the business owner’s or Incident Commander’s approval. These rules must be agreed before an incident.

Does NIS2 require Incident Response procedures?​

NIS2 requires covered entities to implement appropriate risk management measures, including incident handling, business continuity and reporting capability. It does not mandate a particular tool or SOC service, but requires real, documented operational capability. Further detail is available in NIS2 and security monitoring.

What should a post-incident report contain?​

The report should include a timeline, scope, impact, evidence, decisions, the likely cause, containment and remediation actions, recovery status and recommendations with owners and deadlines. It should clearly distinguish established facts from hypotheses.

How can you test an organisation’s cyberattack readiness?​

Run a tabletop exercise and a controlled workflow test: from the alert and on-call contact to isolation and recovery decisions. Also check log completeness, permissions, emergency communications, backup status and implementation of earlier recommendations.

Learn more

• MTTD and MTTR — why detection time determines incident impact
• What a 24/7 SOC is and why monitoring alone is not enough
• Lateral Movement — the attack stage most companies never notice
• Would your company detect ransomware before servers were encrypted?
• Why did SIEM fail to detect ransomware? Common causes and organisational mistakes
• NIS2 compliance audit — how to prepare your organisation