The alert appeared at 2:13 a.m. The administrator saw it at 8:04 a.m.

In this scenario, an endpoint system records an unusual process at 02:13 and an administrator reads the alert at 08:04. In the meantime, an attacker may compromise an account, move through the network and attempt to disable backups. How can alert handling be organised to reduce this delay and its impact?

Key information:

• Monitoring records activity; people create security. Effectiveness depends on people, process and timely response, not the number of deployed tools.
• Detection worked; response was missing. Systems flagged the attack within minutes, but the organization responded only in the morning.
• An alert alone ends nothing. Until someone analyzes and classifies it, the threat continues.
• Business-hours monitoring leaves a gap. Attacks develop at night and on weekends when nobody escalates them.
• Time determines the scale. The longer an alert waits, the wider the attack and the higher recovery costs become.
• Round-the-clock analysis shortens the time to respond. A team reviewing alerts at night turns detection into action that stops the attack.

Why did the system detect the attack?

For management, it was the night’s only good news. Detection investment delivered on time because the tools did exactly what they were bought to do. The problem came afterward.

Three layers contributed to detection:

• EDR (Endpoint Detection and Response)—EDR alerts appear when a process behaves unusually on a device; this produced the first signal at 2:13 a.m.
• SIEM (Security Information and Event Management)—SIEM alerts connect events from multiple systems into one picture and raised severity to High at 2:18 a.m.
• Logs from the firewall, domain controller and identity system—a record that reconstructs exactly what the attacker did and in what order.

Each layer had one task: notice a deviation and record a signal. None was tasked with understanding it. Security alerts were generated correctly and on time, yet the attack continued. Since detection worked, another detection system would change nothing. What was missing was someone to examine the signals at 2:13 a.m.

Why did nobody respond?

At EU directive level, Article 23(4) of NIS2 requires an early warning without undue delay and no later than 24 hours after becoming aware of a significant incident, followed generally by notification within 72 hours of that awareness. A final report is generally due within one month of the notification; ongoing incidents and trust service providers are subject to specific rules. In Poland, the applicable duties, incident classification, competent authority and transitional provisions must be established under the current National Cybersecurity System Act and the rules applicable to the entity. Source: Article 23 of the NIS2 Directive.

An unread alert can delay incident identification and containment, but its timestamp does not automatically start the reporting deadline. The organisation must establish when it became aware of an incident meeting the applicable criteria. Round-the-clock handling supports analysis outside office hours.

Four organizational gaps caused this silence:

• Monitoring only during business hours —night and weekend alerts wait until morning, although the attack does not pause.
• No SOC team —no dedicated people analyze alerts in real time.
• No escalation path —even a noticed signal cannot reach someone authorized to decide on host isolation.
• No playbooks —response depends on the on-call person’s improvisation, not an established procedure.

The lack of response comes down to how work is organized. Someone must read signals outside office hours, and a procedure must tell them what to do next. This is a response-process gap that another tool purchase will not close.

What happened during those six hours?

For a decision-maker, six hours means mounting cost. Each hour moved the incident from detected to expensive as the attacker spread across more systems. The sequence can be reconstructed minute by minute.

The timeline of a single alert:

Time	Attack phase	What happened
02:13 – 02:18	Initial Access	first unusual process, EDR alert and High classification in SIEM
02:41	Privilege Escalation	administrator account compromise and broad network privileges
04:06	Lateral Movement	movement between systems and expansion of the foothold
between 4:06 and 6:58 a.m.	Data Discovery	mapping resources and locating valuable data
06:58	Encryption Preparation	disabling backups and preparing encryption
08:04	Response	the administrator opens the console; the alert has waited almost six hours

The point of no return is 6:58 a.m. An immutable or air-gapped backup would have survived this action, but the attacker disables ordinary domain-connected backup along with the rest. For the decision-maker, the point is clear: incident costs grew with its scope, and scope grew with every hour without response.

Monitoring that ends at alert generation creates an illusion of control: the signal appears, lights up in a console and waits, but does not stop the attacker. At VigilHorizon, the security discussion starts with who analyzes signals at night, then how many systems generate them. Monitoring becomes valuable when alerts are backed by ongoing analysis and response readiness.

Why is an alert only the beginning?

An alert in an inbox can look like a completed task. Effective response starts with the opposite assumption: an alert opens a case rather than closes it. Until people and a procedure act on it, it remains information without an outcome.

The budget implication is concrete: generating alerts is handled by inexpensive automation. The cost lies in steps two through six, which require people and procedures available around the clock.

What would a SOC have done?

The SOC variant illustrates a possible workflow: alert analysis, context assessment, agreed escalation and authorised containment. Timing and effectiveness depend on factors including priority, available telemetry, permissions and conditions in the environment. A 24/7 service alone does not guarantee containment to a single device.

Stage	Without a SOC	With a 24/7 SOC
Alert at 2:13 a.m.	waits in the queue until morning	enters the round-the-clock workflow according to priority
Analysis	only by the administrator after 8:04 a.m.	SOC takes up the incident according to its priority and agreed SLA
Attack progression	continues uninterrupted for six hours	authorised host isolation can restrict further movement
Consequences	growing losses and encrypted data	the impact depends on detection, access and response effectiveness

The core VigilHorizon SOC plan includes event analysis and authorised response within the agreed scope, including containment and coordination of incident handling. Permissions, priorities and SLA conditions are agreed during onboarding. Time to take up an incident is distinct from containment and service recovery time.

Duty coverage is only half the answer; authority to act matters too. Our analyst can isolate an infected host at 2:15 a.m. without waiting for the system owner’s morning decision because the playbook defines permitted nighttime actions and triage establishes urgency. Response accountability follows agreed roles and processes, not technology.

Common organisational mistakes

Each mistake looks harmless on a risk list. The cost becomes clear on incident day, when it turns out that the alert existed but was buried among hundreds of others.

Five mistakes recur most often:

• No 24/7 monitoring —signals outside working hours are not reviewed as they arrive.
• No alert classification —all alerts look alike, so important ones are lost among trivial ones.
• Alert fatigue —a flood of notifications causes analysts to stop responding to new ones.
• No procedures —response depends on whoever happens to answer the phone.
• Too many false alarms —the more false positives there are, the easier it is to miss a real threat.

The common factor is that nobody organizes or continuously analyzes alerts. For decision-makers, this shows the problem lies in work organization, not the number of tools purchased.

How can response time be shortened?

Response time can be measured and reduced. Start with two metrics: MTTD (Mean Time to Detect) indicates how quickly the organization notices a threat, while MTTR (Mean Time to Respond) shows how quickly it responds. In this example, incident detection took minutes, while response took hours; the entire loss lies in that difference.

Four measures genuinely shorten response:

• SOC 24/7 —people analyzing alerts around the clock shorten the window between detection and decision.
• Playbooks and triage automation —prepared scenarios and initial false-positive filtering let analysts focus on what matters.
• Incident Response —structured incident response limits consequences rather than merely describing them.
• Measuring MTTD and MTTR —without numbers, it is impossible to see whether response is improving.

Mature cybersecurity monitoring does not end at detection; it also measures time to response. Moving from hours to minutes takes people, process and timely response added to technology that already works.

Summary

The system detected the threat within minutes, yet the organization remained undefended for six hours. Delayed alert analysis caused the greatest losses: technology worked, but nobody was available to respond. The lesson applies to every company with monitoring but no people at the console.

At VigilHorizon, technology, processes and people operate as one system: tools provide signals, and the team takes responsibility for decisions and response. Response speed is a commitment built into duty coverage and procedures, not a side effect of a well-configured tool.

At VigilHorizon, we start with the same question: who responds to alerts, before counting the systems generating them? We provide incident-time operational capability, not just tools. The natural next step is to assess current monitoring, review MTTD and MTTR, and introduce a SOC 24/7 team that analyzes alerts around the clock.

Frequently asked questions (FAQ)

Does every alert need analysis?​

Every alert needs at least an initial assessment because analysis distinguishes real threats from noise. The depth and speed of assessment vary according to priority.

Does SIEM analyze alerts on its own?​

SIEM automatically correlates and analyses security data. Depending on the product, configuration and integration with SOAR or other tools, it can also trigger approved actions. Incident handling requires a process owner, business context, permissions, escalation rules and oversight of automation.

How can you recognize alert fatigue in a team?​

The first sign is more alerts being postponed instead of classified immediately; the second is a growing delay before an analyst first examines a signal. When both rise, prioritization stops working and important alerts share the noise backlog. Better triage distinguishes threats from background activity before they reach a person; simply reducing alert counts is not the answer.

What should the response time to an alert be?​

There is no universal number, but a reasonable objective is response measured in minutes rather than hours. MTTD and MTTR provide reference points and reveal where the process stalls.

What does a company lose by monitoring only during business hours?​

It loses time, not detection itself. An attack launched in the evening or at a weekend can continue until someone opens the console on Monday. For management, costs grow with each unattended hour regardless of tool count. 24/7 security monitoring shortens the time between a signal and the first human response rather than merely producing more alerts.

Where should you start reducing response time?​

Measure current detection and response times and establish who analyzes alerts outside business hours. Then introduce playbooks, triage automation and round-the-clock SOC monitoring. This sequence identifies the largest gap before spending on new tools.

Learn more

• MTTD and MTTR—why detection time determines incident scale
• What is a 24/7 SOC?
• Incident response—professional cyberattack response, step by step
• SIEM in a company—why deployment alone does not improve security